Есть ли ситуации, где модульные тесты вредны для кода?

Есть ли какие-нибудь «лучшие практики», которые может применяться к дизайну и реализация модульных тестов?

Убедитесь, что ваши модульные тесты не превратились в интеграционные тесты . Например, если у вас есть модульные тесты для класса Foo, то в идеале тесты могут сломаться только в том случае, если

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

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

Один из проектов, над которым я работал, был тщательно протестирован; у нас было более 1000 модульных тестов для 20 или около того классов. Тестового кода было немного больше, чем производственного. Модульные тесты выявляли бесчисленное количество ошибок, возникающих во время операций рефакторинга; они определенно сделали легким и безопасным внесение изменений, расширение функциональности и т. д. В выпущенном коде было очень мало ошибок.

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

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

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

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

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

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

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

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

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

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

Я думаю вы смотрите на устранение симптома, а не на распознавание всей проблемы. Основная проблема заключается в том, что настоящий API - это опубликованный интерфейс *, и он должен иметь те же границы, что и любой программный контракт: никаких изменений! Вы можете добавить к API и назвать его API v2, но вы не можете вернуться и изменить API v1.0, иначе вы действительно нарушите обратную совместимость, что почти всегда плохо для API.

(* Я не t означает вызывать любую конкретную интерфейсную технологию или язык, интерфейс может означать что угодно, начиная с объявлений классов и далее.)

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

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

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

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

Но все это очень маловероятно. Так что они по-прежнему являются тенденцией :)

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

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

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

.