Когда я должен использовать фиктивные объекты?

Я прочитал много вещей о TDD, но у меня все еще есть сомнения. Например, у меня есть эти диаграммы классов:

Это простой пример, просто чтобы узнать о TDD и макете объектов.

Какой тест я должен написать первым? Продукт , затем линия и последний, заказ ? Если я сделаю это, должен ли я использовать Line и Product для тестирования Заказа или использовать Mock Objects? Когда я должен использовать Mock Objects? Должен ли я использовать UML с XP и TDD?

Я еще не получил эти вещи.

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

Нужно ли вам использовать фиктивные объекты, зависит от реальных зависимостей тестируемого класса. Если это простые классы, которые вы можете легко создать и настроить с любыми требуемыми данными / состоянием, необходимыми для ваших тестов, вам не нужны макеты. (Это, кажется, имеет место для вашего примера разработки здесь.) Однако, если какую-либо из зависимостей трудно инициализировать / имеет обширные зависимости сама / имеет нежелательные побочные эффекты / зависит от внешнего ресурса, такого как БД, тогда имеет смысл вместо этого использовать фиктивный объект.

Я не вижу особой необходимости в макете объектов здесь. Как отмечают другие, они нужны в основном, если зависимости трудно установить.

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

Обычно для тестирования вы хотите изолировать тестируемую систему / объект, чтобы вы могли высмеивать все, что находится за ее пределами. Поэтому, используя диаграмму классов, при тестировании объекта заказа используйте макет для объекта строки. При тестировании Line, используйте макет для заказа и продукта. При тестировании продукта используйте макет для Line.

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

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

По поводу насмешек. Если вы хотите издеваться, я предлагаю вам смоделировать Product при написании тестов для Line и mock Line при тестировании Order. Но это может быть излишним здесь. Я лично стараюсь максимально ограничить насмешки и использую его для отделения зависимостей от внешних классов (таких как экземпляры базы данных).