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

27

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

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

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

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

Мэгги
источник
В моей предыдущей компании это был Java EE, Stripes и Struts Framework. Как я уже говорил, сейчас это в основном разработка для iPhone и Android.
Мэгги
TDD означает, что вы пишете тесты перед кодом. Похоже, это было «после факта» тестирования, что является чем-то другим.
менеджеры не заботились о технике, руководитель моей команды настаивал на TDD. это закончилось как комбинация обоих :)
Мэгги
Мэгги, эта статья может показаться вам интересной: fastcompany.com/magazine/06/writestuff.html
Есть какой-то метр для оценки времени? Инструменты для кода JS / .NET?
Хеллбой

Ответы:

16

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

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

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

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

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

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

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

selbie
источник
1
Отличный ответ. Большая часть этого была слишком сложной для тестирования, вы правы в этом. И разделить класс на несколько более мелких блоков, чтобы они лучше подходили для модульных тестов, кажется немного излишним. Я хотел бы приложить код для класса и сопутствующих тестов, и я хотел бы услышать ваше мнение, но я не уверен, что мне позволено. Код не совсем мой, и я больше не работаю в этой компании, поэтому я хотел бы избежать неприятностей.
Мэгги
2
Вот почему вы должны сначала написать тесты. Тогда вы можете найти естественные места, где логика склеивается.
10

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

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


источник
3
И ты выглядишь плохо, когда исправляешь ошибку А только для того, чтобы вводить ошибки B & C.
JeffO
зависит от того, поймали ли тесты B и C или нет
«вы потратите больше времени на обслуживание, чем думаете сейчас» - действительно, особенно с учетом того, что продукты ПО обычно превышают запланированный срок службы, зачастую на много.
Петер Тёрёк
Вы не можете «планировать» иметь долгоживущее приложение, поскольку не можете заранее сказать, будет ли проект успешным или нет. Вы всегда должны учитывать это при составлении бюджета времени на тестирование
Эран Гальперин
1
@Eran, так что вы должны планировать неудачу, чтобы вам не пришлось планировать тесты?
4

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

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

Шон Макмиллан
источник
Да, для меня это так (на самом деле я обычно переключаюсь между работой над тестами и работой над кодом продукта каждые несколько секунд , а не минут). Так что я, вероятно, работаю над тестами 100% времени.
Джонатан Хартли
2

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

OZ_
источник
4
Почему у людей такая паранойя отладки? Если вы знаете инструменты, вы редко сталкиваетесь с проблемой, отладка которой занимает более 5 минут. Проблемы, которые трудно отладить, в основном связаны с многопоточностью, но модульные тесты там в любом случае бесполезны.
Кодер
3
@ Кодер, потому что люди имеют опыт и знают, что тесты гораздо полезнее, чем слепая отладка.
OZ_
2
Зависит. Модульные тесты часто приводят к обратным результатам и добавляют ложное чувство безопасности. И в хорошо структурированном коде вы не столкнетесь с проблемой «слепой отладки». У тебя проблема, ты знаешь, где искать. Если вы этого не сделаете, сделайте полный обзор кода / дизайна. Также см .: programmers.stackexchange.com/questions/86636/…
кодер
4
Это проблема многих сторонников TDD, они враждебно настроены против отладки и проектирования, полагаясь на тесты, чтобы найти все ошибки. Затем в рабочем коде приложения теряют память, обрабатывают и аварийно завершают работу на многоядерных процессорах, и они похожи на «WTH». TDD - это всего лишь инструмент, и в зависимости от поставленной задачи он может быть либо очень продуктивным, либо очень контрпродуктивным. Попробуйте написать юнит-тесты для всех сложных случаев в связанном посте, и вы никогда не отправите продукт.
Кодер
1
«Если вы знаете инструменты, вы редко сталкиваетесь с проблемой, отладка которой занимает более 5 минут». - @Coder Интересно, на какие приложения вы смотрите.
Кирк Бродхерст
2

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

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

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

Петер Тёрёк
источник
у вас есть опыт работы с мобильными приложениями? Каково было бы приемлемое соотношение тест / разработка для простого мобильного приложения?
Мэгги
@ Мэгги, к сожалению, нет. (Поэтому, если бы мне нужно было написать один, я бы, вероятно, потратил больше, чем обычно, на модульное тестирование :-)
Péter Török