TDD предполагает, что интерфейсы уже определены;как справиться?

Question

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

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

Существуют ли передовые методы, чтобы облегчить это?

Answer 1

Звучит как вся петля красно-зелёного рефактора. То есть TDD - это - что-то вроде - в этом переписывании интерфейсов. Это делает их стройными и точными. Как только вы освоите TDDing и напишите свои тесты, ориентированные на интерфейс, и сделаете ваши объекты небольшими, вы не увидите больших изменений, если не наткнетесь на что-то непредвиденное и должны адаптироваться, что является моментом гибкости ( надеюсь, почему ты TDDing)

Звучит так, будто вы определяете целые интерфейсы за один раз. Что было бы неправильно. Один тест должен генерировать одну функцию в интерфейсе, и это ожидаемое поведение. Ваш интерфейс будет расширяться вместе с набором тестов, что сводит к минимуму дальнейшее исправление ошибок.

Answer 2

Так же, как вы пишете тесты , как если бы код, который вы тестируете, уже был написан, вы можете (и должны) писать их, как если бы интерфейс уже был написан. Это Design часть - самая важная часть - Test-Driven Design . Вы знаете, какую функциональность вы собираетесь запросить у тестируемого класса; напишите тест, как будто эта функциональность уже была там. Имена и параметры, которые вы используете сейчас, в своем тесте; что естественно происходит с вами, думая как клиент тестируемого кода и интерфейса; Эти элементы играют важную роль в дизайне вашего класса и его интерфейса.

Answer 3

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

TDD - тестовый дизайн - разработка означает изменение интерфейсов.

Answer 4

Я согласен с @Per Fagrell -s "Интерфейс будет расти со временем".

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