Заставляет ли меня разработка, основанная на тестировании, следовать SOLID?

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

Вызывает ли TDD разработчиков более активное следование SOLID, чем просто написание модульных тестов?

Прежде всего, TDD не заставляет вас строго писать код SOLID. Вы можете сделать TDD и создать один большой беспорядок, если хотите.

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

Если вы уже знакомы с принципами SOLID, TDD предложит вам подумать о них и активно их использовать.

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

Например:

1. Вам нужно написать несвязанный код, чтобы вы могли высмеивать то, что вам нужно. Это поддерживает принцип инверсии зависимости .
2. Вам нужно написать тесты, которые будут четкими и краткими, чтобы вам не пришлось слишком сильно менять их в тестах (которые могут стать большим источником шума кода, если это будет сделано иначе). Это поддерживает принцип единой ответственности .
3. С этим можно поспорить, но принцип сегрегации интерфейса позволяет классам зависеть от более легких интерфейсов, которые упрощают отслеживание и понимание mocking, потому что вам не нужно спрашивать: «Почему эти 5 методов также не подвергались насмешкам?», Или что еще более важно, у вас нет большого выбора, когда вы решаете, какой метод издеваться. Это хорошо, когда вы на самом деле не хотите просматривать весь код класса перед его тестированием и просто использовать метод проб и ошибок, чтобы получить общее представление о том, как он работает.

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

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

Самое важное, что принципы SOLID были созданы, чтобы побудить вас писать более чистый, понятный и понятный код, как и TDD. Поэтому, если вы правильно выполняете TDD и обращаете внимание на то, как выглядит ваш код и ваши тесты (и это не так сложно, потому что вы получаете немедленную обратную связь, API и правильность), вы можете меньше беспокоиться о принципах SOLID в целом.

нет

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

Мое понимание Принципов SOLID расширилось на порядок, когда я начал заниматься TDD. Как только я начал думать о том, как имитировать зависимости, я понял, что практически каждый компонент в базе кода имеет потенциальную альтернативную реализацию. И насколько проще протестировать простой публичный API.

Это также обеспечило более глубокое понимание большинства шаблонов проектирования. Особенно шаблон стратегии.

да : TDD - это в основном хорошая методика проектирования (и только вторичная методика тестирования). Это очень помогает в достижении твердых принципов, хотя (патологические) примеры TDD с большим количеством запахов кода все еще возможны.

Связь между TDD и основополагающими принципами оспаривается (с заключением выше) в этом замечательном подкасте Hanselminute под названием «Разработка через тестирование - это дизайн - последнее слово в TDD» .