Создание фиктивных данных для модульного тестирования

Question

Я считаю себя все еще довольно новым для сцены TDD. Но обнаружите, что независимо от того, какой метод я использую (макет фреймворка или создание своих собственных объектов), я нахожу, что мне нужно написать много кода для создания фиктивных данных. Мне нравится идея загрузки объектов для создания базы данных в памяти. Но что мне не нравится, так это засорение моих тестов тонной кода с единственной целью создания фиктивных данных. Это особенно верно, когда данные должны учитывать все разные случаи.

Мне бы хотелось несколько советов для лучшего способа сделать это.

Мне кажется, что я должен быть в состоянии загрузить данные один раз в известное состояние из некоторого хранилища данных, а затем я мог бы использовать снимок этого состояния, который загружается в настройке / инициализации теста перед каждым методом тестирования казнены. Это удовлетворяло бы надлежащим методам тестирования, обеспечивая удобство, и позвольте мне сосредоточиться на написании тестов вместо написания кода для создания тестовых данных «вручную».

Answer 1

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

Answer 2

Если вы используете .Net Попробуйте NDBUnit

Вы заполняете свой магазин, а затем он возвращает вашу БД в известное состояние во время теста для каждого теста. Сериал Осень проворной демонстрирует это довольно подробно.

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

Answer 3

У вас может быть класс (ы) Builder, который поможет вам создавать нужные вам экземпляры / в этом случае те, которые вы будете использовать, связанные с репозиторием. Пусть Builder использует соответствующие значения по умолчанию, и на ваших тестах вы можете перезаписать то, что вам нужно. Это поможет вам избежать необходимости смешивать каждый отдельный случай «данных» для всех разных тестов (что создает проблемы, потому что обычно есть случаи, которые не совместимы для разных тестов).

** Обновление 1: ** Взгляните на www.markhneedham.com / blog / 2009/01/21 / c-builder-pattern-все-таки полезный для теста-данных

Answer 4

Покаs.org освещает этот путь лучше, чем я когда-либо мог.

Их руководство действительно очень хорошее.

Но, по сути, если вашим юнитам требуется «много данных», они могут больше не быть юнит-тестами. Я бы порекомендовал попробовать испытать мелкие кусочки по отдельности.

Answer 5

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

То, что действительно было бы хорошо, было бы структурой, которая позволяла бы мне использовать мой существующий DAL или для сценария данных для кода для меня, или для получения данных в памяти и доступа к ним как к базе данных в памяти.

Answer 6

Я точно знаю, что вы имеете в виду. Я думаю, что хороший подход к решению этой проблемы - на самом деле иметь отдельный проект MockFramework, в котором хранятся все ваши фиктивные данные вне тестового проекта. Таким образом, вы можете генерировать фиктивные данные отдельно, сохранять их в памяти, если хотите, или нет, а затем ссылаться на макет фреймворка из тестового проекта. Если вы используете стороннюю платформу для этого, тем лучше, но вы все равно можете обернуть эту стороннюю платформу в свою собственную фиктивную платформу, чтобы вы могли получить весь этот «клей», который создает фиктивные данные так, как вам нужно ваши тесты, так что тесты действительно могут быть только такими, какими они должны быть.