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

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

Я хотел бы получить несколько предложений по лучшему способу сделать это.

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

Ответов (6)

Решение

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

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

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

** Обновление 1: ** Взгляните на www.markhneedham.com/blog/2009/01/21/c-builder-pattern-still-useful-for-test-data

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

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

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

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

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

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

Все их руководство на самом деле очень хорошее.

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