Выполняя TDD, когда внедрять новую издеваемую зависимость?

Question

Есть один вопрос, на который я не могу найти ответ, касающийся TDD с внешним подходом:

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

Выполняю ли сначала (B), и пусть мои тесты для (A) терпят неудачу, потому что я еще не реализовал его, чтобы пройти тесты?

Или я сначала заполняю (A), а между тем пропускают тесты для (B), потому что это, например, просто возвращает «пустые» объекты, а не выполняет то, что его спецификация говорит ему делать?

Нужно ли мне (B) проверять, что он возвращает «пустые» объекты, пока я продолжаю реализовывать (A), - хотя на самом деле это не та спецификация (B)?

Answer 1

Основополагающая стратегия TDD заключается в том, чтобы держать все ваши тесты проходящими, за исключением того, над которым вы сейчас работаете. Пройдите тесты (A), прежде чем вы беспокоитесь о (B).

Порядок, в котором вы бы писать тесты и код для класса (А) и его сложной зависимости (B) является

• Написать тест для (A). [Люкс красный.]
• Начните выполнять достаточно (A), чтобы получить тест, который вы только что написали, чтобы пройти. Узнайте, что вам нужно (B). [Люкс красный.]
• Mock (B). [Люкс красный.]
• Закончите проверку (A), которую вы только что написали. [Люкс зеленый. Ahhh!] Рефактор.
• Если вы еще не достигли хорошей точки остановки (A), вернитесь к вершине и повторите, пока вы не достигнете хорошей точки остановки (A).
• Напишите тест для (B), который требует (B) выполнить часть или все, что делает макет (B). [Люкс красный.]
• Сделайте тест, который вы только что написали. [Люкс зеленый. Ahhh!] Рефактор.
• Если вы не воспроизвели все то, что макет (B) в тестах и ​​код (B) еще нет, вернитесь на два шага и повторите, пока вы не воспроизведете все то, что делает mock of (B) ,

На данный момент вы можете выбрать работу над (A) или (B) или начать что-то новое.

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

Приемочные тесты (или другие интеграционные тесты) также гарантируют, что вы правильно копируете mocks в своих тестах и ​​код для издевающихся классов.

Обратите также внимание на то, что очень важно отслеживать требования, о которых вы думали, но еще не реализованы, или что вы «реализовали» только в макете и нуждаетесь в реализации в тестах и ​​коде для издеваемой зависимости , Вот почему TDD By Example и другие примеры того, как делается TDD, так много говорят о реальных или мысленных списках дел.В случае класса (A) с издетой зависимостью (B) после того, как вы напишете mock, вы можете либо вернуться к работе над (A), либо реализовать в (B) то, что вы только что сделали с макетом. В любом случае, вы должны следить за тем, что вы выбрали , а не, пока вы не готовы вернуться и сделать это.

Answer 2

Я предлагаю иметь зависимость от B только после того, как вам действительно понадобится B в вашем коде. Если ничто в A не зависит от B, зачем добавлять его на этом этапе?

Если вам действительно нужен код B, почему бы не начать реализацию функций B, которые вам нужны сейчас?

Конечно, вы также можете использовать фиктивный объект в своем коде вместо B, если он не имеет никакой логики. В противном случае я бы начал внедрять B.