Опрос о контрастной дисперсии в TDD - PullRequest
0 голосов
/ 29 марта 2020

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

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

Затем я должен реорганизовать тесты тоже. (вот где у меня возникло недоразумение)

Об этом шаге, дядя Боб, сказал:

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

Мои вопросы: Как определить связь? Что он подразумевает под «добавлением аргументов конструктора в X или повышением уровня абстракции аргументов, которые я передаю в X». и "polymorphi c интерфейс между XTest и X."

Пример кода будет очень кстати !! :):)

Ссылка на данную статью блога: https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.html

Заранее благодарны.

1 Ответ

2 голосов
/ 30 марта 2020

Как определить связь?

Начните с этой heuristi c: если изменение здесь требует, чтобы вы также сделали изменение там, тогда у вас есть связь между ними.

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

Быть тесно связанным с неустойчивыми вещами - это жалкое существование.

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

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

Если вместо того, чтобы начинать с «Мне нужен FooClass и, следовательно, FooTest», вы начинаете с "Мне нужно FooBehavior и, следовательно, FooTest"; тогда вы намного ближе к цели, чтобы иметь детектор ошибок, который вы можете использовать без изменений , пока вы выполняете итерацию реализации этого поведения.

С другой стороны, когда само поведение нестабильно, это не поможет. В этом случае вам понадобятся другие методы. См. Речь Рича Хичи Spe c -уляция , где он говорит о силе аккреции.

...