TDD и ответственное проектирование - как совместить тестирование с процессом проектирования?

Question

«Лондонский стиль» TDD предлагает сосредоточиться на ролях объектов, обязанностях и совместной работе, используя фиктивные объекты для вытеснения слоев крупномасштабного проектирования компонентов в нисходящем процессе (в отличие от «классического стиля», который фокусируется на алгоритмическом уточнении).методов).

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

Ценю некоторые реальные советы.

Answer 1

:)

«Лондонский стиль» - это, по сути, хороший ООП в сочетании с TDD, управляемым внешним (приемочным тестом) (я предполагаю, что вы имеете в виду подход, подобный книге ГСНО ),Это способ, которым это «должно» быть сделано;хотя «классические» люди должны были быть более откровенными об этом.Я не уверен, что среди практикующих есть такая классификация (хотя есть люди, которые быстрее с TDD, и люди, которые борются с ним).Основанные на состоянии и взаимодействии являются стилями и не подходят для всех размеров.Вам нужно выбрать стиль для поставленной задачи.

Проблема с «TDD в углу» заключается в том, что вы можете в конечном итоге получить хорошо протестированный код, который работает, но все же делает неправильные вещи с точки зрения клиентов..

Теперь Evolution подтолкнула нас к циклу ATDD, то есть TDD, выполняемому на уровне заказчика / приемки, который управляет внутренним циклом TDD для разработчиков, чтобы пройти приемочный тест.

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

Answer 2

Я не вижу необходимости согласовывать TDD (в любой форме) с «естественным» дизайном компонентов. Тестирование подразумевает, что у вас есть представление о том, что вы тестируете, по крайней мере, у вас есть интерфейс с некоторым уровнем точности. Начиная с грубого определения компонента, мне кажется очень «естественным».