Когда к модульному тесту против ручного теста

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Делает ли этот код то, что я думаю делает?

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

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

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

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

Каждое приложение проверяется.

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

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

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

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

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

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

Ответ 11

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

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

Ответ 12

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

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

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

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

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

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

Ответ 13

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

TDD, в смысле "написать неудачный тест, написать код, чтобы пройти тест, рефакторинг, повторить" Обычно наиболее эффективен и полезен при написании тестов unit.

Вы пишете unit test вокруг только класса/функции/единицы кода, над которым работаете, используя mocks или заглушки, чтобы абстрагировать остальную часть системы.

"Автоматизированное" тестирование обычно относится к более высокоуровневым интеграционным/приемным/функциональным испытаниям - вы можете делать TDD вокруг этого уровня тестирования, и это часто единственный вариант для сильно управляемого кода, но вы должны знать, что этот вид тестирования является более хрупким, сложнее писать тест-во-первых и не заменяет модульное тестирование.

Ответ 14

TDD дает мне, как разработчику, уверенность в том, что изменение, которое я вношу в код, имеет намеченные последствия и ТОЛЬКО предполагаемые последствия, и поэтому метафора TDD как "сети безопасности" полезна; изменить любой код в системе без него, и вы не можете понять, что еще вы могли сломать.

Инженерное напряжение между разработчиками и тестировщиками - действительно плохая новость; разработчики культивируют "хорошо, тестерам платят, чтобы найти ошибки" (приводящие к лени), и тестерам - кажется, что они не видят, что они выполняют свою работу, если они не находят каких-либо ошибок - бросают как можно больше тривиальных проблем. Это грубая трата каждого времени.

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

Ответ 15

Тестирование модулей - это не то же самое, что функциональное тестирование. Что касается автоматизации, то ее обычно следует учитывать, когда цикл тестирования повторяется более чем в 2 или 3 раза... Это предпочтительнее для регрессионного тестирования. Если проект мал или он не будет иметь частых изменений или обновлений, то ручное тестирование является более эффективным и менее экономичным вариантом. В таких случаях автоматизация окажется более дорогостоящей с записью и поддержкой script.