Непрерывная интеграция всегда должна сочетаться с разработкой, управляемой тестами?

Question

Непрерывная интеграция всегда должна сочетаться с разработкой, управляемой тестами?

2

Я участвую в проекте, в котором мы используем сервер непрерывной интеграции и NUnit для тестирования модулей и интеграции.

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

Я хотел бы знать, можем ли мы по-прежнему рассматривать наш процесс разработки как следующий шаг Agile Development, сказать это клиентам и не лгать.

yeyeyerman 03 нояб. 2009, в 09:31

Источник

Теги:

c#

continuous-integration

agile

3 ответа

4

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

Konamiman 03 нояб. 2009, в 04:51

1

В отсутствие автоматических тестов CI проверяет только, что код под контролем источника поддерживается в компилируемом состоянии между версиями и что одноэтапная сборка работает правильно. Хотя это полезно, это не так полезно, как автоматическая проверка того, что правильность кода поддерживалась между версиями.

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

sal 03 нояб. 2009, в 12:07

Ещё вопросы

Johannes Rudolph · Accepted Answer · 2009-11-03T05-38-00.000Z

Я думаю, вы смешиваете вещи здесь.

Test-Driven-Development (TDD) не обязательно означает, что вы используете гибкий подход. Наверняка, это лучшая практика, что многие из нас, которые делают гибкое использование, но TDD также могут быть использованы в процессе водопада, заменяя/дополняя спецификацию.

Непрерывная интеграция сама по себе означает наличие кода, который ваша команда производит интегрированным, по крайней мере, ежедневно. Это не только заставляет каждого члена команды постоянно сливаться/регистрироваться, но также гарантирует, что вы действительно можете сделать выпуск каждой сборки. Унифицированный процесс сборки заставляет вас преодолеть "работу над моим машинным синдромом". Поскольку вы можете делать выпуск каждый день, это поддерживает гибкий процесс, хотя он не является абсолютно необходимым в строгом смысле.

Использование тестов и их интеграция в процесс сборки - это способ обогащения вашего процесса сборки автоматическим обеспечением качества и углубления уровня, на котором фактически протестирована интеграция (целостность).