Следует ли писать макеты для модульных тестов в отдельный коммит? - PullRequest
Новая
       56

Следует ли писать макеты для модульных тестов в отдельный коммит?

3 голосов
/ 18 июня 2020

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

Как я пишу в TDD, прежде чем писать код logi c я пишу модульные тесты.
Тесты иногда зависят от новых моков, чье первое (и единственное) использование - это тесты. Применяя вышеупомянутый принцип, я не хочу коммитить насмешки сами по себе. Таким образом, я завершаю коммит модульных тестов и моков в одном коммите.

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

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

1 Ответ

2 голосов
/ 18 июня 2020

Самая важная политика в отношении Git коммитов состоит в том, что каждый коммит должен проходить сборку . Можно было бы возразить, что с TDD имело бы смысл фиксировать каждый шаг цикла красный / зеленый / рефакторинг, например:

  • Red, совершить (но не делайте этого)
  • Зеленый, фиксация
  • Рефакторинг, фиксация

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

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

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

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

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

...