, поэтому мой вопрос заключается в том, как будет выглядеть последовательность коммитов, когда мы будем следовать TDD
TDD, по большей части, на самом деле мало что говорит this.
Обычная практика - никогда не делиться изменениями, когда тесты КРАСНЫЕ; причина в том, что, как правило, даже один тестовый сбой приводит к сбою сборки, а это означает, что ваша преднамеренная фиксация неудачного теста блокирует другие исправления и функции, которые стоят за вами, после развертывания в производство.
Теперь, если фиксация сломанного теста не провалит сборку (надеюсь, потому что тест намеренно исключен из выполнения, а не потому, что наш конвейер сборки мягок), тогда может иметь смысл зафиксировать неудачные тесты.
Когда я строю ветку в git, чтобы показать, как я могу TDD что-то, я делаю неработающие тесты, чтобы наглядно продемонстрировать каждую из задач RED / GREEN / REFACTOR. Но эти демонстрации отличаются от вышеупомянутых случаев в двух важных отношениях
- Они не являются общими; никто не будет заблокирован, когда они объединят мои изменения
- Нет никакого конвейерного применения, что "все тесты пройдены", потому что развертывания вообще нет.
Test Commit / Revert (TCR) - это другая привычка кодирования, которая в некоторой степени связана с TDD. Основная идея заключается в том, что когда вы запускаете свои тесты локально, вы получаете один из двух результатов
- Все тесты проходят успешно, поэтому ваши последние изменения автоматически фиксируются (обычно с сообщением фиксации общего назначения )
- Любой из тестов не пройден, поэтому ваши последние изменения автоматически отбрасываются
... что означает, что вы не можете зафиксировать тест без кода, который бы его прошел.
Один из случаев, когда тесты без кода действительно отстой? git -bisect ; если я пытаюсь отследить странную проблему между двумя коммитами, твой коммит "тесты не проходят" между моим хорошим коммитом и плохим коммитом может закончиться для меня дополнительной работой в контексте, где мы уже с счастливого пути.