Управление нагрузкой на обслуживание модульных тестов

Сначала кодирование - я обнаружил, что, возможно, 3/4 моего кода - это модульные тесты; если бы я был действительно экстремальным и не писал строку кода, кроме как исправить неудачный unit test, это соотношение было бы еще выше. Поддержание всех этих модульных тестов добавляет огромное количество инерции для изменения кода. В начале, я сосать его и исправить. Как только возникает давление, я заканчиваю каталогом broken_unit_tests, чтобы пересмотреть "когда есть время". Похоже, что TDD слишком быстро распространяется, прежде чем дизайн успеет кристаллизоваться.

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

Ответы

Ответ 1

Сохраняя аспект Дисциплины Программиста в стороне... (это личное дело, если вы в порядке с регистрацией, не создавая приятеля или не фиксируя все тесты. Agile предполагает высокую дисциплину.. и Courage & Поддержка оставайтесь на правильном пути под давлением:),

Если вы обнаружите, что при выполнении одного изменения не удается выполнить несколько тестов, его запах, что что-то не так с вашими тестами. Хрупкие тесты распространены, когда вы начинаете с TDD... если вы тратите больше времени на исправление своих тестов, чем на исправление кода... останавливайтесь, дышите и размышляйте. Исправьте болезнь, а не симптом.
Если у вас есть фрагменты кода, мы могли бы обсудить. Как бы то ни было, я не думаю, что могу помочь вам многое... Рекомендация:. Тест должен завершиться неудачно только по одной причине. Напротив, каждый неудачный тест должен указывать точное уникальное местоположение дефекта. Два теста не должны терпеть неудачу из-за того же изменения. Если вы не делаете изменения уровня архитектуры, это должно быть редкими.

Ответ 2

Думаю, у тебя все наоборот. При реализации изменения, которое может сломать unit test, вы должны сначала обновить модульные тесты. Таким образом, вы никогда не получите сломанный unit test и рабочий код. У вас либо будет сбой unit test, потому что код еще не готов или обе части будут работать нормально.

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

Также вы можете попробовать работать в короткие циклы. То есть вместо

  • Сделайте много изменений
  • Исправить множество модульных тестов
  • Повторите

Try

  • Планируйте небольшое изменение
  • Измените соответствующие unit test (s)
  • Изменить соответствующий код
  • Повторите

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

Ответ 3

Единичные тесты должны быть довольно неизменными.

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

Теперь, очевидно, в некоторых случаях вам может потребоваться переписать тест, если вы измените контракт API, но по большей части вы не должны рассматривать "переписать тест" как допустимый способ сделать TDD.

Ответ 4

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

Вообще-то я не сторонник TDD.:)

Ответ 5

Ваш тест, вероятно, недостаточно сфокусирован, или у вас слишком много зависимостей в ваших системах.

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

Не уверен, что он на 100% очищен...