Как вы справляетесь с TDD в непрерывной интеграции?
Представьте, что вы реализуете пользовательскую историю, содержащую различные новые функции и усложняющую кодовую базу. Существующий код довольно хорошо покрыт, и вы только что определились с интерфейсами. Вы начинаете реализовывать функционал, начиная с тестов.
Теперь у вас есть довольно сложные тестовые примеры, основанные на требованиях, но реализация еще далека от того момента, когда вы сможете зафиксировать полностью рабочий код SCM, а многие тесты терпят неудачу (как и должны).
Предполагается, что при непрерывной интеграции все сборки должны быть зелеными, если это возможно, и поэтому вы не должны коммитить, так как вы нарушите сборку. Но и не стоит "Погаснуть" и такое количество кода оставлять себе ...
Какая процедура предлагается в такой ситуации?
Ответы 2
Не выбирайте заранее интерфейсы все. Постепенно развивайтесь в типичном ритме TDD: напишите тест; пройти тест; рефакторинг. Это должно поддерживать все в хорошей форме, полоса всегда будет зеленой, и вы можете проверять код, не беспокоясь о том, что вы нарушите сборку.
Это требует другого стиля написания кода, но со временем вы привыкнете к ритму.
Петр, я не имел в виду, что люди должны заниматься взломом без какого-либо концептуального анализа. Анализ и цель кода все еще там. Только с формой пока не определись ;-). Мой опыт работы с юниорами показывает, что они создают лучший код, когда вы говорите им писать тесты.
Как насчет того, чтобы пропустить те тесты, которые, как вы знаете, не пройдут, потому что функциональность в настоящее время отсутствует?
Дайте понять, что вы тоже пропускаете тесты! Действительно заставить его кричать «как застрявшая свинья», как говорят в Оз! (-:
По мере добавления функциональности включайте связанные тесты и сохраняйте «зеленую полосу»!
Вот еще одна отличная статья из The Pragmatic Programmers, который рассказывает о том, как сделать разбитые окна очевидными для других.
HTH
ваше здоровье,
Роб
Я считаю, что начинать взламывать без какого-либо концептуального анализа - это плохо. Это приводит к неудовлетворительному и иногда не очень логичному коду. Представьте, что вы находитесь не в идеальной ситуации, когда все члены команды имеют одинаковую квалификацию, но есть и значительное количество юниоров.