Когда проводить юнит-тест против ручного теста

Question

Несмотря на то, что модульное тестирование кажется эффективным для более крупных проектов, где API должны быть промышленно сильными (например, разработка API-интерфейсов .Net Framework и т. Д.), Оно может показаться избыточным в небольших проектах.

Когда лучше всего подходит автоматизированный подход TDD, а когда лучше использовать методы ручного тестирования, регистрировать ошибки, сортировать их, исправлять и т. Д.

Еще одна проблема - когда я был тестером в Microsoft, нам подчеркивали, что было важно, чтобы разработчики и тестировщики были разными людьми, и что напряженность между этими двумя группами могла бы помочь создать отличный продукт в конец. Может ли TDD сломать эту идею и создать ситуацию, когда разработчик может оказаться неподходящим человеком для тщательного поиска собственных ошибок? Это может быть автоматизировано, но может показаться, что существует множество способов написания тестов, и что сомнительно, будет ли данный набор тестов «доказывать», что качество приемлемо.

Answer 1

Эффективность TDD не зависит от размера проекта. Я буду практиковать три закона TDD даже на самых маленьких упражнениях по программированию. Тесты не требуют много времени для написания, и они экономят огромное количество времени на отладку. Они также позволяют мне реорганизовать код, не боясь что-либо сломать.

TDD - это дисциплина, аналогичная дисциплине бухгалтерии с двумя записями, практикуемой бухгалтерами. Это предотвращает ошибки в малом. Бухгалтеры будут вводить каждую транзакцию дважды; один раз как кредит, а один раз как дебет. Если не было допущено ни одной простой ошибки, баланс будет сведен к нулю. Этот ноль является простой выборочной проверкой, которая не позволяет руководителям попасть в тюрьму.

Точно так же программисты пишут модульные тесты перед своим кодом в качестве простой выборочной проверки. По сути, они пишут каждый бит кода дважды; один раз как тест, и один раз как производственный код. Если тесты пройдены, два бита кода будут согласованы. Ни одна из этих практик не защищает от более крупных и сложных ошибок, но обе эти практики, тем не менее, ценны.

Практика TDD на самом деле не техника тестирования, это практика разработки. Слово «тест» в TDD является более или менее совпадением. Таким образом, TDD не является заменой хороших методов тестирования и хороших тестировщиков качества. Действительно, очень хорошая идея, чтобы опытные тестировщики писали планы QA-тестирования независимо (и часто заранее) от программистов, пишущих код (и их модульные тесты).

Я предпочитаю (на самом деле, моя страсть), чтобы эти независимые тесты контроля качества также автоматизировались с помощью такого инструмента, как FitNesse , Селен или Watir . Деловые люди должны легко читать тесты, выполнять их и совершенно недвусмысленно. Вы должны иметь возможность запускать их в любой момент, обычно много раз в день.

Каждая система также должна быть проверена вручную. Тем не менее, ручное тестирование никогда не должно быть запоздалым. Тест, который может быть написан по сценарию, должен быть автоматизирован. Вы только хотите поставить людей в петлю, когда человеческое суждение необходимо. Поэтому люди должны проводить исследовательские испытания , а не слепо следовать планам испытаний.

Итак, краткий ответ на вопрос о том, когда проводить юнит-тестирование по сравнению с ручным, заключается в том, что «против» не существует. Вы должны написать автоматические модульные тесты сначала для подавляющего большинства кода, который вы пишете. Вы должны иметь автоматизированные приемочные тесты, написанные тестерами. И вы должны также практиковать стратегическое поисковое ручное тестирование.

Answer 2

Модульные тесты не предназначены для замены функциональных / компонентных тестов. Модульные тесты действительно сфокусированы, поэтому они не будут воздействовать на базу данных, внешние сервисы и т. Д. Интеграционные тесты делают это, но вы можете сфокусироваться на них. Суть в том, что по конкретному вопросу ответ заключается в том, что они не заменяют эти ручные тесты. Теперь автоматизированные функциональные тесты + автоматизированные тесты компонентов, безусловно, могут заменить ручные тесты. От проекта и подхода к нему будет зависеть многое от того, кто на самом деле это сделает.

Обновление 1: Обратите внимание, что если разработчики создают автоматизированные функциональные тесты, вы все равно хотите проверить, что они имеют соответствующее покрытие, дополняя их соответствующим образом. Некоторые разработчики создают автоматизированные функциональные тесты со своей структурой «модульных» тестов, потому что им все равно приходится проводить тесты дыма независимо от модульных тестов, и это действительно помогает автоматизировать их :)

Обновление 2: Модульное тестирование не является излишним для небольшого проекта, а также не автоматизирует дымовые тесты или не использует TDD. Что является излишним, так это то, что команда делает это впервые в небольшом проекте. Выполнение любого из них имеет связанную кривую обучения (особенно модульное тестирование или TDD), и не всегда будет выполнено правильно вначале. Вы также хотите, чтобы кто-то, кто занимался этим какое-то время, помог бы избежать ловушек и вставил некоторые проблемы с кодированием, которые не очевидны при его запуске. Проблема в том, что команды не имеют таких навыков.

Answer 3

Согласно исследованиям различных проектов (1), модульные тесты обнаруживают 15..50% дефектов (в среднем 30%). Это не делает их худшим средством поиска ошибок в вашем арсенале, но и не серебряной пулей. Там нет никаких серебряных пуль, любая хорошая стратегия обеспечения качества состоит из нескольких методов.

---

Автоматизированный тест выполняется чаще, поэтому он раньше обнаруживает дефекты и значительно снижает их общую стоимость, что является истинной ценностью автоматизации тестирования.

Мудро инвестируйте свои ресурсы и сначала соберите низко висящий фрукт.
Я считаю, что автоматизированные тесты проще в написании и обслуживании для небольших модулей, изолированных от кода функций и классов. Функциональность конечного пользователя легче тестируется вручную - и хороший тестировщик найдет много странностей помимо обязательных тестов. Не настраивайте их друг против друга, вам нужны оба.

---

Dev против тестеров Разработчики, как известно, плохо тестируют свой собственный код: причины являются психологическими, техническими и не в последнюю очередь экономичными - тестеры обычно дешевле разработчиков. Но разработчики могут внести свой вклад и упростить тестирование. TDD делает тестирование неотъемлемой частью построения программы, а не просто запоздалой мыслью, которая является истинной ценностью TDD.

---

Еще один интересный момент о тестировании: нет смысла в 100% покрытии. Статистически, ошибки следуют правилу 80:20 - большинство ошибок находится в небольших разделах кода. Некоторые исследования предполагают, что это еще острее - и тесты должны быть сосредоточены на тех местах, где появляются ошибки.

---

(1) Продуктивность программирования Jones 1986 ua., Цитата из Code Complete, 2nd. редактор Но, как говорили другие, тесты unit - это только одна часть тестов, интеграционные, регрессионные и системные тесты могут быть - по крайней мере частично - автоматизированы.

Моя интерпретация результатов: "многие глаза" лучше всего обнаруживают дефекты, но только если у вас есть какой-то формальный процесс, который заставляет их действительно выглядеть.

Answer 4

Я бы сказал, что юнит-тесты помогают программистам ответить на вопрос:

Этот код делает то, что я думаю делает

Это вопрос, который им нужно задать себе много. Программисты любят автоматизировать все, что они делают, где только могут.

Отдельная группа тестирования должна ответить на другой вопрос: -

Делает ли эта система то, что я (и конечные пользователи) ожидаю? сделать? Или меня это удивляет?

Существует целый огромный класс ошибок, связанных с тем, что программист или дизайнеры имеют другое представление о том, что правильно, когда юнит-тесты никогда не будут запущены.

Answer 5

TDD - лучший подход, когда это возможно. Тестирование TDD является автоматическим, поддающимся количественной оценке с помощью покрытия кода и надежным методом обеспечения качества кода.

Ручное тестирование требует огромного количества времени (по сравнению с TDD) и страдает от человеческой ошибки.

Ничто не говорит о том, что TDD означает только тест разработчиков. Разработчики должны отвечать за кодирование процентной доли тестовой среды. QA должен нести ответственность за гораздо большую часть. Разработчики тестируют API так, как хотят. QA тестирует API-интерфейсы способами, о которых я никогда бы не подумал, и делаю вещи, которые, хотя и кажутся сумасшедшими, на самом деле делаются клиентами.

Answer 6

Я полагаю, что возможно объединить опыт QA / персонала тестирования (определение тестов / критериев приемлемости) с концепцией TDD использования API, принадлежащего разработчику (в отличие от GUI или HTTP / интерфейса обмена сообщениями), для управления тестируемое приложение.

По-прежнему крайне важно иметь независимый персонал для контроля качества, но нам больше не нужны огромные команды ручного тестирования с современными инструментами тестирования, такими как FitNesse, Selenium и Twist.

Answer 7

Будучи на обеих сторонах, проводя тестирование и разработку, я бы утверждал, что кто-то всегда должен вручную проверять ваш код. Даже если вы используете TDD, есть множество вещей, которые вы, как разработчик, не сможете покрыть модульными тестами или не подумать о тестировании. Особенно это касается удобства использования и эстетики. Эстетика включает в себя правильное написание, грамматику и форматирование вывода.

Пример из реальной жизни 1:

Разработчик создавал отчет, который мы показываем в нашей внутренней сети для менеджеров. Было много формул, все из которых разработчик тестировал до того, как код пришел в QA. Мы убедились, что формулы действительно дают правильный результат. То, что мы попросили исправить, почти сразу же, исправило тот факт, что числа отображались розовым на фиолетовом фоне.

Пример из реальной жизни 2:

Я пишу код в свободное время, используя TDD. Мне нравится думать, что я проверяю это полностью. Однажды моя жена прошла мимо, когда у меня появилось диалоговое окно с сообщением, прочитало его и быстро спросило: «Что на земле это сообщение должно означать?» Я думал, что сообщение было довольно ясным, но когда я перечитал его, я понял, что речь идет о родительских и дочерних узлах в древовидном элементе управления, и, вероятно, не будет иметь смысла для обычного пользователя. Я перефразировал сообщение. В данном случае это была проблема с удобством использования, которая не была обнаружена моим собственным тестированием.

Answer 8

Ваш вопрос, кажется, больше об автоматическом тестировании, чем о ручном тестировании. Модульное тестирование - это форма автоматического тестирования, но очень специфическая форма.

Ваше замечание о наличии отдельных тестировщиков и разработчиков прямо на высоте. Но это не означает, что разработчики не должны выполнять какую-либо форму проверки.

Модульное тестирование позволяет разработчикам быстро получать отзывы о том, что они делают. Они пишут тесты для быстрого запуска небольших блоков кода и проверки их правильности. Это на самом деле не тестирование в том смысле, что вы, кажется, используете слово «тестирование» так же, как проверка синтаксиса компилятором не тестирует. Модульное тестирование - это методика разработки. Код, который был написан с использованием этой методики, вероятно, более высокого качества, чем код, написанный без, но все же должен пройти контроль качества.

На вопрос об автоматизированном тестировании и ручном тестировании для отдела тестирования легче ответить. Когда проект становится достаточно большим, чтобы оправдать затраты на написание автоматических тестов, вы должны использовать автоматические тесты. Когда у вас есть много небольших одноразовых тестов, вы должны делать их вручную.

Answer 9

модульное тестирование кажется эффективным для более крупных проектов, где API должны быть промышленно сильными, возможно, это похоже на излишество в небольших проектах.

Это правда, что модульные тесты движущегося API являются хрупкими, но модульное тестирование также эффективно в проектах без API, таких как приложения. Юнит-тестирование предназначено для тестирования юнитов, из которых сделан проект. Это позволяет гарантировать, что каждый блок работает как положено. Это реальная сеть безопасности при изменении - рефакторинге - кода.

Что касается размера проекта, то правда, что написание юнит-тестов для небольшого проекта может быть излишним. И здесь я бы определил небольшой проект как небольшую программу, которую можно протестировать вручную, но очень легко и быстро, всего за несколько секунд. Также может вырасти небольшой проект, и в этом случае может быть выгодно иметь под рукой модульные тесты.

было важно, чтобы разработчики и тестировщики были разными людьми, и что напряженность между этими двумя группами могла бы помочь в конечном итоге создать отличный продукт.

Каким бы ни был процесс разработки, модульное тестирование не предназначено для того, чтобы заменить другие этапы тестирования, а дополнить его тестами на уровне разработки, чтобы разработчики могли получить очень раннюю обратную связь, не дожидаясь официальной сборки. и официальный тест. Благодаря модульному тестированию команда разработчиков предоставляет код, который работает, в нисходящем направлении, не код без ошибок, но код, который может быть протестирован группой (-ами) тестирования.

Подводя итог, я тестирую вручную, когда это действительно очень просто, или когда написание юнит-тестов слишком сложно, и я не стремлюсь к 100% охвату.

Answer 10

Каждое приложение проходит проверку.

Некоторые приложения проходят тестирование в форме, когда мой код компилируется и код выглядит как function .

Некоторые приложения тестируются с Модульными тестами . Некоторые разработчики не верят в модульные тесты, TDD и покрытие кода ошибкой. Как и все, слишком много чаще, чем не плохо.

К счастью, некоторые приложения достаточно протестированы через команду QA . Некоторые команды QA автоматизируют свое тестирование, другие пишут тестовые примеры и тестируют вручную.

Майкл Фезерс, который написал: Эффективно работает с устаревшим кодом , написал, что код, не обернутый в тестах, является устаревшим кодом. Пока вы не испытали Big Ball of Mud , я не думаю, что какой-либо разработчик действительно понимает преимущества хорошей архитектуры приложений и набора хорошо написанных модульных тестов.

Отличная идея - тестирование разных людей. Чем больше людей сможет просмотреть приложение, тем больше вероятность того, что будут рассмотрены все сценарии, включая те, которые вы не собирались реализовывать.

TDD недавно получил плохой рэп. Когда я думаю о TDD , я думаю о догматических разработчиках, которые тщательно пишут тесты до того, как они напишут реализацию. Хотя это и так, но при написании тестов (сначала или вскоре после этого) разработчик испытывает метод / класс в шкуре потребителя. Недостатки и недостатки дизайна сразу бросаются в глаза.

Я утверждаю, что размер проекта не имеет значения. Что важно - это срок жизни проекта. Чем дольше проект живет, тем больше вероятность, что над ним будет работать другой разработчик, а не тот, кто его написал. Юнит-тесты - это документация, соответствующая ожиданиям приложения - своего рода руководство.