Контроль версий и разработка через тестирование

Question

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

Есть ли что-то, что позволяет вам проверить версию x тестового кода, версию x-1 рабочего кода и увидеть, что тесты, написанные вами в версии x, не пройдены? (Я бы заинтересовался любым языком и системой контроля версий, но я использую ruby ​​и git)

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

Answer 1

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

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

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

Но все равно смотрите, как тест не пройден.

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

Answer 2

Просто храните свои тесты и код в отдельных каталогах, и тогда вы можете проверить одну версию тестов и другую код.

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

Я бы тоже усомнился в мотивации для этого? Если сначала «провести» неудачный тест, то я бы указал на этот комментарий от отца (продвижение) TDD.

Answer 3

Пара вещей:

1. После рефакторинга теста вы снова запускаете тест
2. Затем вы реорганизуете код, затем снова запускаете тест
3. Тогда вам не нужно регистрироваться сразу, но вы могли бы

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

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

Answer 4

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

Затем вы можете добавить дополнительные тесты, убедиться, что они также не пройдены, git commit, git merge, а затем запустить тесты с текущей базой кода, чтобы увидеть, приведет ли уже выполненная работа к выполнению теста или если вы Теперь нужно сделать еще немного работы.

Answer 5

Есть ли что-нибудь, что позволяет вам проверить версию X тестового кода, и ревизия х-1 производства код, и увидите, что тесты вы написано в ревизии х не удалось?

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

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

Как всегда, я направлю вас в Википедию для общего описания по теме . А более подробным, довольно известным ресурсом была бы статья Мартина Фаулера

Answer 6

Если вы храните свой производственный и тестовый код в отдельных областях управления версиями (например, в отдельных проектах / деревьях исходного кода / библиотеках и т. Д.), Большинство систем контроля версий позволяют извлекать предыдущие версии кода и перестраивать их. В вашем случае вы могли бы проверить версию производственного кода x-1, перестроить ее, а затем запустить тестовый код для вновь развернутого или развернутого производственного кода.

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