Что такое хороший рабочий процесс git для TDD?

Мне нравится модель ветвления Gitflow
http://nvie.com/img/git-model@2x.png
но я не уверен, куда поместить цикл TDD - должен ли я просто использовать ветвь функции и фиксировать каждый раз, когда я писал или проходил тест (плюс после рефакторинга)? Создать дочернюю ветвь и объединить "готовые" единицы в ветвь объектов? Должен ли я совершать каждый провальный тест или только после его прохождения?

вот что я сейчас делаю, на функции бранч:

  1. написать тест, commit
  2. тест может привести к ошибкам из-за несуществующих интерфейсов, исправить это, изменить commit
  3. сделайте (теперь только неудачный) тестовый проход, измените commit
  4. рефакторинг, новая фиксация
  5. Гото 1
20
git git-flow tdd workflow

5 ответов

Я не уверен, что это представитель, но просто говорю как один разработчик, я использую git-flow и вот (грубо) мой рабочий процесс для новой функции:

  • создать отдельную ветку
  • напишите неудачный приемочный тест высокого уровня (огурец), который терпит неудачу с @wip (работа в процессе) тег, так что он остается вне набора тестов на данный момент, и зафиксировать это в новой ветви
  • (иногда) напишите тест запроса rspec для интеграционного тестирования крайних случаев, и зафиксируйте это в ветке функции
  • напишите тесты нижнего уровня (rspec / jasmine) для отдельных компонентов функции и для каждого грубо определенного "блока" зафиксируйте ветвь функции
  • когда функция будет завершена достаточно, чтобы она прошла приемочный тест, снимите @wip тег, убедитесь, что он проходит и фиксируется в ветке функции
  • слить ветку в ветке develop, используя git merge (а не git flow finish). Это оставляет ветку там, чтобы я мог обновить функцию позже, если это необходимо.
  • как только филиал объединяется для разработки, travis-ci запускает полный набор тестов на нем, и если есть какие-либо проблемы, я получаю электронное письмо. (Я включаю только ветви develop и master в свой .Трэвис.файл yml.)

Я должен сказать, это мой "идеальный" рабочий процесс - на практике я часто нарушаю эти правила: совершаю непроверенные изменения перед написанием теста, начинаю работать над частями функции, прежде чем на самом деле fleshing вне высокопоставленное приемочное испытание, etc. Я в основном единственный, кто привержен проекту, поэтому у меня есть свобода делать это; если вы работаете в большой группе, я думаю, вам нужно быть более строгим в отношении соблюдения любого рабочего процесса.

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

обновление:

я понял, после написания этого, что есть одно чувство в который я отклоняюсь от вышеуказанного потока, когда я добавляю "функции", которые, строго говоря, не являются нормальными ориентированными на пользователя (т. е. не вещи, о которых пользователь будет знать). Например, в начале разработки приложения мы решили использовать backbone.js для структурирования нашего кода js-поэтому я создал для него ветку функций и добавил @javascript теги для различных существующих функций огурца. Я объединил его обратно, как только ветка была примерно в состоянии сделать (с позвоночником.js) каким было оригинальное приложение выполнение с представлениями HTML.

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

7

Я думаю, что хорошим и простым ориентиром будет совершать каждый раз, когда вы "зеленый", или, по крайней мере, каждые тест:

  • Красный -> Зеленый -> Рефакторинг -> Commit
  • или красный -> зеленый -> Commit -> рефакторинг -> Commit
3

простой способ подумать о том, когда вы должны совершить:

  1. могу ли я описать, что я совершаю с сообщением фиксации, которое имеет смысл?
  2. есть ли какие-либо причины, по которым я мог бы захотеть вернуться к этой точке или отличаться от этой точки?

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

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

2

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

1

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

  1. написать тест, git добавить.
  2. тест может привести к ошибкам из-за несуществующих интерфейсов, исправить это, git добавить.
  3. сделайте (теперь только неудачный) тестовый проход, git commit.
  4. рефакторинг, git commit amend.
  5. Goto 1.

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

0