В настоящее время я изучаю TDD и пытаюсь применить его на практике в своих личных проектах. Я также широко использовал контроль версий во многих из этих проектов. Я заинтересован во взаимодействии этих двух инструментов в типичном рабочем процессе, особенно когда дело доходит до максимума, чтобы коммиты оставались небольшими. Вот несколько примеров, которые приходят на ум:
Я начинаю новый проект и пишу простой тест для создания еще не существующего класса. Должен ли я выполнить тест перед написанием класса, даже если тест даже не компилируется? Или я должен заглушить минимальный объем кода, необходимый для компиляции теста перед его фиксацией?
Я нахожу ошибку и пишу тест, чтобы воссоздать ее. Должен ли я выполнить неудачный тест или реализовать исправление ошибки, а затем зафиксировать?
Это два примера, которые сразу приходят на ум. Не стесняйтесь приводить дополнительные примеры в своем ответе.
Редактировать:
В обоих примерах я сделал предположение, что сразу после написания теста я напишу код для прохождения теста. Может также возникнуть другая ситуация: я работаю над проектом с использованием TDD в течение нескольких часов без коммитов. Когда я наконец делаю коммиты, я хочу разбить свою работу на маленькие кусочки. (Git делает это относительно легко, даже если вы хотите зафиксировать только некоторые изменения в одном файле.)
Это означает, что мой вопрос касается как того, что совершать, так и вопроса о том, когда совершать.
источник
Нет.
Нет.
Вы говорите о двух парадигмах здесь:
Моя рекомендация: следуйте по кругу TDD, пока ваш код не скомпилируется, ваши тесты не станут зелеными, и вы сможете внести свой вклад в систему. Поэтому вы должны сократить свои возможности по вертикали, например, для новой маски пользовательского интерфейса не создавайте всю форму и не выполняйте фиксацию без бизнес-логики, а скорее реализуйте один крошечный аспект, но во внешнем интерфейсе, а также бизнес-логике и на уровне персистентности ,
Для большого исправления фиксируйте после каждого улучшения (например, рефакторинг), даже если ошибка еще не исправлена. Тесты должны быть зелеными, а код должен компилироваться.
источник
Конечно, вы начинаете с использования здорового исходного кода, такого как git.
Тогда вы можете работать так, как вам нравится, и совершать действия на каждом углу - любой шаг или подшаг - это честная игра.
Затем, перед тем как добавить материал, вы сводите всю работу в один коммит. Или пара, в точках, где все зелено и композиция имеет смысл. И подтолкнуть эти разумные коммиты. Для нескольких случаев сделайте это ветвью, которую вы объединяете с --no-ff.
Источник контроля не является системой отслеживания работы или историком. В коммитах должна быть представлена разумная когерентная дельта, в то время как состояние проверки должно составлять как минимум. Промежуточные звенья могут быть сохранены на некоторое время для ознакомления, но как только все будет в порядке, один коммит для каждой функции будет справедливым.
источник
В моем понимании мира человек обязуется отметить точку, к которой, возможно, было бы желательно вернуться. Точка a, в которой тест не пройден (но компилируется), определенно является одной из таких точек. Если бы мне пришлось отклониться в неверном направлении, пытаясь пройти тест, я хотел бы иметь возможность вернуть код обратно в исходную точку и повторить попытку; Я не могу сделать это, если я не совершил.
источник
С разветвленной SCM (я видел, что вы используете Git) вы должны фиксировать всякий раз, когда вам нужна точка резервного копирования («Я что-то испортил; я сброслю рабочий каталог до последней точки резервного копирования») или когда у вас стабильная версия. Если у вас стабильная версия (все тесты пройдены), вам также следует рассмотреть возможность слияния текущей функциональной ветви с основной веткой разработки.
На ваше усмотрение (git дает вам гибкость, позволяющую совершать коммиты в любое время, не затрагивая других членов вашей команды, или вашу способность работать с различными функциями). Просто убедитесь, что у вас нет нескольких незавершенных (нерабочих) функций в одной ветви одновременно (тогда они будут блокировать друг друга).
Я обычно делаю для этого два коммита, если только тестовый код не слишком мал / тривиален для написания.
Это может быть неправильным предположением. Если вы работаете один (личный проект), ничто не мешает вам всегда делать это. В одном из моих самых успешных проектов (в отношении поддержания высокого качества кода и TDD на протяжении всей разработки проекта) мы определяли тесты иногда за несколько недель до их реализации (то есть мы бы сказали, что «тест« test_FOO_with_null_first_parameter »теперь определен как пустая функция и зафиксируйте это так). Затем мы бы взяли спринт (или половину спринта) иногда через месяц или около того, чтобы просто увеличить охват тестами для модуля. Так как у нас уже были объявлены тесты, это было легко оценить.
Я бы сказал, определенно обязуюсь создавать резервные точки . Это очень хорошо работает для исследовательского тестирования («я просто добавлю несколько распечаток по всей базе кода, запуском и
git reset --hard
удалением их, когда я закончу) и для прототипирования.источник
В моем рабочем процессе, когда это возможно, я делаю неопределенную работу в личной ветке контроля версий. Так что я могу попробовать, потерпеть неудачу, повторить попытку, если это необходимо, до тех пор, пока это не сработает, и выполнить коммит в большем проекте только тогда, когда у меня есть действующий рабочий код.
С точки зрения TDD, вопрос «Вы сначала проходите тестирование?» полностью зависит от кода, над которым вы работаете. Если это новый код, вы ничего не регистрируете, пока не найдете что-то стоящее. Но если это ошибка, обнаруженная в уже скомпилированном или поставленном коде, стоит проверить в тесте, чтобы воспроизвести ошибку, ПО СЕБЕ, стоит проверить. Особенно, если это конец рабочего дня, и вы покинете офис до того, как исправите код.
(Конечно, если в вашем магазине есть автоматизированный процесс сборки, который умирает, если какие-либо юнит-тесты не пройдены, вы можете не захотеть проверять неудачный тест, пока не исправите ошибку. Но это кажется странным способом работы, так как "find и "ошибки в документах" и "исправлять ошибки" могут делать две совершенно разные команды.)
источник