Большие данные модульного теста
Знание grep и рубин позволили сузить проблему и проверить фиксацию для, проблема, включающая тонны исключений Java на некоторых рабочих серверах. Поскольку я бросил решение вместе в рубин, оно было сделано (разработанный, реализованный, протестированный, выполненный, зафиксированный к ошибке, повторно выполнитесь, улучшенный, проанализированные результаты), днем вместо нескольких дней. Я, возможно, решил ту же проблему с помощью решения все-Java или решения C#, но она, скорее всего, возьмет меня дольше.
Имеющее динамическое экспертное знание языка также иногда приводит Вас к простым решениям на менее динамических языках. В рубине, жемчуге или Python, Вы просто интуитивно достигаете ассоциативных массивов (хеши, словари, безотносительно слова Вы хотите использовать) для пустяков, где Вы могли бы испытать желание создать сложную иерархию классов на статически типизированном языке, когда проблема не обязательно требует его.
Плюс Вы может включить большинство языков сценариев в большую часть времени выполнения. Таким образом, это не должен быть либо/либо.
5 ответов
What как выглядят ваши тесты?
Вы уверены, что пишете модульные тесты, а не тесты более высокого уровня для нескольких компонентов вашего кода? Чистый модульный тест должен вызывать только один метод, и мы надеемся, что этот метод будет иметь ограниченные вызовы других методов (возможно, через имитацию ).
Сосредоточившись на наименьшей возможной единице, вы можете написать код для проверки конкретных крайних случаев. В то время как, если вы тестируете на более высоком уровне, вам часто придется писать все типы перестановок крайних случаев. Как только вы охватите все самые маленькие единицы, вы можете написать несколько интеграционных тестов более высокого уровня, чтобы убедиться, что все эти единицы собраны правильно.
Например, если бы у меня было приложение, которое считывает CSV-файл котировок акций и средних значений все цитаты для данного дня, я бы написал несколько тестов:
- Модульные тесты вокруг синтаксического анализа CVS
- Модульные тесты вокруг группировки дат
- Модульные тесты вокруг усреднения
- Модульные тесты вокруг отображения ответ
- И небольшое количество интеграционных тестов, которые могут взять очень небольшой CVS-файл и передать его через весь процесс.
Прошу прощения, если я делаю предположения относительно ваших модульных тестов, но из мой опыт, Я обнаружил, что часто то, что люди называют модульными тестами, не являются настоящими модульными тестами, а скорее интеграционными (или как вы предпочитаете их называть, например, функциональными тестами и т. Я лично очень виноват в написании слишком общих тестов, и каждый раз, когда я сейчас пишу тесты, мне приходится заставлять себя помнить, что нужно действительно тестировать модуль за раз.
Вы не могли программно создать подмножество элементов из контролируемого набора данных реальных производственных данных? Это то, что мы делаем, и если каким-то образом модель данных изменилась, у нас есть несколько скриптов, которые обновляют эти реальные данные до новой модели, прежде чем использовать их в тестах.
Я бы хотел порекомендовать xUnit Test Patterns: Refactoring Test Code от Джерарда Месароса.
Этот случай напоминает запах General Fixture :
Возможное решение Чтобы решить эту проблему, нам нужно перейти к минимальному креплению. Лучше всего это можно сделать, используя Fresh Fixture для каждого теста. Если нам необходимо использовать Shared Fixture, нам следует рассмотреть возможность применения рефакторинга Make Resource Unique для создания виртуальной песочницы базы данных для каждого теста. (Обратите внимание, что переключение на неизменяемый общий прибор (см. Общий прибор) не решает полностью суть этой проблемы, поскольку не помогает нам определить, какие части прибора необходимы для каждого теста; таким образом идентифицируются только те части, которые были изменены. !)
Метод большой. Это ужасно в управлении и делает набор тестов огромным.
У меня есть отдельная программа для генерации тестовых данных. Сгенерированные тестовые данные хранятся на диске, контролируются версиями и доступны / используются в модульных тестах. Размер / сложность этой программы (например, у нее есть собственный пользовательский интерфейс) не влияет на размер / сложность самих модульных тестов.
Это решение проблемы «сложно сгенерировать данные» (но я не рекомендовал бы его для генерации гигабайт тестовых данных, которые, возможно, лучше сгенерировать на лету).
Кроме того, я делаю это для интеграционных тестов (не модульных тестов).
Сколько тестовых сценариев поддерживает этот набор тестовых данных?
В идеале, ваши тестовые данные должны быть разбиты так, чтобы были отдельные наборы тестовых данных для каждого сценария . В противном случае ваши тестовые сценарии косвенно зависят друг от друга, что в любом случае является злом.
Другими словами, наличие в нескольких сценариях одного и того же набора данных создает возможность того, что изменение общего набора данных для одного сценария непреднамеренно сделает данные несовместимыми с другим. сценарий.