Как профессиональный разработчик, допустимо ли не писать модульные тесты? [закрыто]

Интересно узнать о плюсах и минусах TDD / автоматизированного модульного тестирования и узнать мнение сообщества о том, приемлемо ли для профессиональных разработчиков писать приложения без поддержки модульных тестов?

Чтобы проверить что?

Если вы говорите о 100% покрытии кода, это крайне редко, бесполезно и часто невозможно. Точно так же тестирование кода, связанного с CRUD, является пустой тратой времени, и было бы крайне непрофессионально тратить часы на написание ненужного кода вместо того, чтобы делать что-то действительно полезное.

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

теория

Существует распространенное заблуждение, что юнит-тесты предназначены для тестирования «юнитов» .
Модульные тесты, также как и все остальные тесты, тестирование функциональности . Там просто ничего не может быть проверено.

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

Еще раз, это не гарантирует, что вся система будет работать, но это упрощает тестирование.

TDD не является требованием само по себе. Это упрощает кодирование, заставляя разработчика сначала ответить: «Что я на самом деле собираюсь кодировать?».

Расходы

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

Допустим, вы допустили ошибку в своем коде и обнаружили и исправили ее в тот же день. Стоимость составляет X долларов .
Давайте предположим, что ошибка остается незамеченной и переходит к еженедельной внутренней сборке. К счастью, QA обнаружил это, поднял ошибку в трекере, проблема была предметом 5-минутного обсуждения на встрече из 5 человек и т. Д. Наконец, вы исправили это. Стоимость - это сумма трудовых ресурсов, потраченных каждым, и в этом случае она может составить 3 * Х.
Что если ошибка пошла на бета-тестирование и привлекла больше людей? Давайте скажем, $ 10 * X .
Если он остается незамеченным в течение долгого времени, его посетили 1000 клиентов (надеюсь, не миллион!), 10 из них обнаружили это, они подняли дискуссию с вашим обслуживающим персоналом, некоторые могут называться вашим начальником, ваши товарищи по команде пытаются воспроизвести его. и т. д. и т. д. Наконец, ошибка возвращается к вам, и вы исправляете это. Сколько всего? Ну более чем $ 50 * X .

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

Pro,

• Модульные тесты позволяют разработчику лучше кодировать . Так просто.
• Они позволяют сэкономить ваше время;
• Они уменьшают затраты;
• Модульные тесты живут вместе с кодом, который они тестируют. После любого запроса на изменение (который происходит постоянно) тесты будут адаптированы.

Con-х

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

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

По моему опыту, 95% ошибок, которые могут быть обнаружены модульными тестами, происходят из-за обращений к уровню данных, особенно после изменения структуры базы данных. Если вы используете базу данных, просто проверьте каждый метод, который вы используете для доступа к ней. Тесты даже не должны быть сложными, просто проверки работоспособности.

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

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

TDD - это не только написание тестов. Речь идет о том, чтобы ваш код легко тестировался. И чаще всего легко тестируемый код также легче читать / отлаживать / поддерживать. Чаще всего тестируемый код также следует шаблонам и принципам OO, таким как SOLID. Я бы сказал, как профессиональный разработчик, ваш код всегда должен быть написан таким образом.

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

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

Я собираюсь выйти на конечность здесь и сказать, что это в основном субъективно и зависит от ваших целей. tl; dnr: Это хорошо, но быть догматичным по этому поводу просто приведет к большему количеству проблем.

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

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

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

Так что, вероятно, будет какая-то функция

• Размер команды / оборот
• Желаемый срок годности приложения
• Приложение и насколько критичны сбои
• Время, предоставленное для внедрения лучших практик относительно графика разработки
• Командные способности (это не означает, что быть хорошим программистом означает, что вы не должны писать модульные тесты, но команда без младших разработчиков могла бы с большим успехом летать за штанами)

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

Это профессионально, чтобы написать ремонтные модульные тесты, которые сэкономят ваше время и слезы!

Существует misconception that Unit test finds bugs. Ну, это просто не верно для всех случаев. Модульное тестирование не связано с обнаружением ошибок или обнаружением регрессий. Это по определению examine each unit of your code separately. Но когда ваше приложение работает по-настоящему, все эти модули должны работать вместе, и все это более сложное и тонкое, чем сумма его независимо протестированных частей.

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

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

Как профессиональный разработчик, допустимо ли не писать модульные тесты?

Нет.

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

Насколько тщательными должны быть эти юнит-тесты?

Вот лакмусовая бумажка: если QA обнаружит ошибку в вашем коде, будете ли вы чувствовать себя комфортно, используя свои тесты, чтобы доказать свою должную осмотрительность своему боссу?

Если ваш ответ «Нет», то вам следует составить более качественный модульный тест (или тесты).
Если ваш ответ «Да», значит, ваш код готов к проверке.

Как профессиональный разработчик допустимо не писать автоматические модульные тесты?

Да.

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

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