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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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