Почему я записал бы поддельный класс и модульный тест это?

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

Это в основном так, чтобы можно было протестировать классы по одному, не имея необходимость тестировать все классы, от которых они также зависят.

Не тестируйте ложный класс. Действительно протестируйте производственный класс с помощью ложного класса.

Смысл тестового класса поддержки должен иметь что-то, что можно предсказать его поведение. Если необходимо протестировать тестовый класс поддержки для предсказания его поведения, существует проблема.

В поддельной статье базы данных Вы связались в комментарии, автору нужна к модульному тесту его поддельная база данных, потому что это - его продукт (по крайней мере, в контексте статьи).

Править: обновленные условия, чтобы быть более последовательным.

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

Вы не должны тестировать ложный класс.

То, что Вы обычно делаете: Вы создаете ложные классы для всех классов, с которыми взаимодействует класс, который Вы тестируете.

Скажем, Вы тестируете класс под названием Велосипед, который берет в объектах конструктора классов Колесо, Седло, HandleBar, и т.д.

И затем в классе Ездят на велосипеде Вы, Вы хотите протестировать, тестируют его метод GetWeight, который, вероятно, выполняет итерации через каждую часть и называет свойство/метод Weight их и затем возвращает общее количество.

Что Вы делаете:

• Вы пишете ложный класс для каждой части (Колесо, седло и т.д.), который просто реализует бит Веса
• затем Вы передаете те ложные классы Велосипеду
• протестируйте метод GetWeight на Велосипедном классе

Это тот способ, которым можно сфокусироваться на тестировании GetWeight на Велосипедном классе способом, который независим на других классах (говорят, что они еще не реализованы, не детерминированный и т.д.),

Вы пишете "поддельный" класс под названием Тупиковый или Фиктивный объект, потому что Вы хотите протестировать реализацию простым способом, не тестируя реальный реальный класс. Цель состоит в том, чтобы упростить тестирование путем тестирования только Интерфейса (или абстрактный класс).

В Вашем примере Вы тестируете что-то, что имеет словарь. Это могло бы быть, заполняются в реальном базой данных или имеют большую логику позади него. В Вашем "поддельном" объекте можно упростить все при наличии всех постоянных данных. Таким образом, Вы тестируете только поведение интерфейса и не, как конкретный объект создается.

Кто наблюдает за наблюдателями?

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

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

Вместо того, чтобы писать фальшивый класс самостоятельно, вы можете использовать инструмент (например, Rhino или Typemock ), чтобы имитировать его. Это намного проще, чем писать все макеты самому. И, как говорили другие, нет необходимости тестировать поддельный код, который не является кодом, если вы используете этот инструмент.

На самом деле я нашел два применения для фиктивных классов, которые мы используем при тестировании реализации репозитория.

Первый - это тестирование служб, использующих реализацию эквивалента ISomethingRepository, который вы упоминание. Однако наши реализации репозитория создаются фабрикой. Это означает, что мы пишем тесты для «ISomethingRepository», но не напрямую для «MockSomethingRepository». Проверяя интерфейс, мы можем легко утверждать, что покрытие кода для наших тестов покрывает 100% интерфейса. Проверки кода обеспечивают простую проверку того, что новые элементы интерфейса протестированы. Даже если разработчики упрекают нас в том, что фабрика возвращается, сервер сборки имеет другую конфигурацию, которая проверяет конкретную реализацию, возвращаемую фабрикой в ​​ходе ночных сборок. Он обеспечивает лучшее из обоих миров с точки зрения тестового покрытия и локальной производительности.

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

Поскольку используемые нами фабрики связаны с тем, какой «ISomethingRepository» возвращать, у нас есть локальные конфигурации тестирования, конфигурации тестирования сборки , производственные конфигурации и т. д. Мы намеренно пытаемся убедиться, что ни у одной команды проекта нет необоснованного времени ожидания из-за времени реализации другой команды. Самый большой отрезок времени ожидания по-прежнему предоставляется командой разработчиков, но мы можем запускать наши доменные объекты, репозитории и сервисы быстрее, чем внешняя разработка.

Конечно, YMMV. ; -)

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

Конечно, YMMV. ; -)

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

Конечно, YMMV. ; -)

и услуги более быстрыми темпами, чем фронтенд разработка.

Конечно, YMMV. ; -)

и услуги более быстрыми темпами, чем фронтенд разработка.

Конечно, YMMV. ; -)