Большие данные модульных испытаний

Question

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

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

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

Какой совет?

Answer 1

Как выглядят ваши тесты?

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

Сосредоточившись на наименьшей возможной единице, вы можете написать код для проверки конкретных крайних случаев. Принимая во внимание, что если вы тестируете на более высоком уровне, вам часто придется писать все типы перестановок в граничных случаях. Когда у вас есть все самые маленькие блоки, вы можете написать несколько интеграционных тестов более высокого уровня, чтобы убедиться, что все эти блоки собраны правильно.

Например, если бы у меня было приложение, которое считывает в CSV-файл котировки акций и усредняет все котировки за определенный день, я бы написал несколько тестов:

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

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

Answer 2

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

Answer 3

Сколько тестовых сценариев поддерживает этот набор тестовых данных?

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

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

Answer 4

Я бы хотел порекомендовать xUnit Test Patterns: рефакторинг тестового кода от Gerard Meszaros.

Этот случай напоминает запах General Fixture :

Возможное решение Нам нужно перейти к Minimal Fixture, чтобы решить эту проблему. Лучше всего это сделать, используя Fresh Fixture для каждого теста. Если мы должны использовать Shared Fixture, мы должны рассмотреть возможность применения рефакторинга Make Resource Unique для создания виртуальной песочницы базы данных для каждого теста. (Обратите внимание, что переключение на неизменяемое общее устройство (см. Общее устройство) не полностью решает суть этой проблемы, поскольку не помогает нам определить, какие части устройства необходимы для каждого теста; только идентифицированные части определены !)

Answer 5

Метод большой. Это ужасно в управлении и делает массивный набор тестов.

У меня есть отдельная программа для генерации тестовых данных. Сгенерированные тестовые данные хранятся на диске, контролируются версиями и доступны / используются в модульных тестах. Размер / сложность этой программы (например, она имеет собственный интерфейс) не влияет на размер / сложность самих модульных тестов.

Это решение "сложно генерировать данные" (но я бы не рекомендовал его для генерации гигабайт тестовых данных, которые, возможно, лучше генерировать на лету).

Кроме того, я делаю это для интеграционных тестов (не юнит-тестов).

Answer 6

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