сколько времени вы тратите на юнит-тестирование?

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

В результате, однако, я многое узнал о TDD, инструментах тестирования, методах и т. Д.

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

Теперь, как работающий не по найму, я задаюсь вопросом - сколько времени действительно необходимо потратить на юнит-тестирование? Какие части кода, будучи в основном разработчиками для iPhone / Android, должны быть рассмотрены в тестах?

Необходимое количество юнит-тестирования зависит от нескольких факторов:

• Размер продукта (чем больше проект, тем больше нужно включить хотя бы несколько юнит-тестов)
• Требуемый уровень качества (если вы быстро собираете программное обеспечение, которое должно быть выпущено как можно быстрее, а некоторые незначительные ошибки приемлемы, то вам может быть необходимо пропустить некоторые тесты, такие как модульное тестирование)
• Тип продукта (пользовательский интерфейс может быть модульным тестированием, но иногда проще пропустить модульное тестирование в тяжелых разделах графического интерфейса проекта и вместо этого выполнить тестирование вручную)
• Ваша способность / история кодирования (Какие ошибки вы обычно создаете? Это те вещи, которые обычно тестирует Unit Testing, или вещи, которые обычно находит другой тип тестирования. Знание этого может подтолкнуть вас к более или менее модульному тестированию)

В нашей группе продуктов мы нацелены на 50-70% покрытия кода от модульных тестов и 90% + покрытия от модульных тестов и автоматизации тестирования вместе взятых. Типичное время, затрачиваемое на написание модульных тестов, составляет около 1 дня для каждой функции, которая занимает 3-4 дня бездумного кодирования. Но это может варьироваться в зависимости от многих факторов.

Покрытие кода на 99% отличное. Модульные тесты отличные. Но 99% покрытия кода только от модульного тестирования? Мне трудно поверить, что вы можете получить такое большое освещение только за счет модульного тестирования .

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

Но вы сказали, что три дня написания теста были только для одного класса. Возможно, сам класс не был предназначен для модульного тестирования. Реализует ли класс пользовательский интерфейс? Сеть? Файловый ввод / вывод? Если это так, вы могли бы написать больше кода для тестирования среды выполнения Java, чем ваша бизнес-логика, взаимодействующая со средой выполнения.

TDD заставляет задуматься об интерфейсах и интерфейсах с зависимостями. Тот единственный класс, который реализует пользовательский интерфейс, сеть и file / io для одной функции, может быть лучше разделен на несколько классов - один для работы в сети, один для file / io и пользовательский интерфейс, разбитый на конструкцию контроллера модели-просмотра. Затем вы можете реализовать соответствующие тесты для каждого с простыми фиктивными объектами для зависимостей. Конечно, все это занимает больше времени. Таким образом, вместо 1 дня на кодирование и 3 дня на написание тестов, этот тип проектирования может потребовать 3 дня написания кода и 1 день написания тестов. Но код будет гораздо лучше поддерживать и многократно использовать.

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

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

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

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

Если вы не будете тратить время на тесты, вы потратите еще больше времени на отладку в живом коде.
Поэтому потратьте столько времени, сколько нужно на тестирование, чтобы покрыть весь (или 99% кода).

Как уже отмечали другие, это во многом зависит от типа программного обеспечения. Упомянутое вами соотношение времени тестирования / разработки 3: 1 может быть слишком большим для средних проектов, но может быть вполне приемлемым для критически важных приложений и даже слишком малым для жизненно важной системы.

Покрытие модульных тестов на 99 +%, возможно, слишком много, чтобы ожидать в случае среднего приложения, но слишком мало для жизненно важного проекта.

По моему опыту, учитывая, что значительная часть производственного кода является кодом обработки ошибок, охват для большинства приложений будет достаточным для охвата 80-90%, и это может потребовать примерно столько же времени, сколько потрачено на написание модульных тестов, что и производственный код. (Опять же, если кто-то искренне работает в режиме TDD, они полностью переплетаются, превращаясь практически в одну задачу, поэтому можно только догадываться о фактическом соотношении.)