junit: тесты, которые полагаются друг на друга - PullRequest
2 голосов
/ 11 марта 2012

У меня архитектурная дилемма относительно JUnit Тестовой структуры.

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

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

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

Есть идеи, как создать набор тестов?

Ответы [ 2 ]

3 голосов
/ 11 марта 2012

То, что вы описываете, является интеграционным тестом , а не модульным тестом. Модульные тесты (в идеале) не должны полагаться на файловую систему, объем доступной памяти и т. Д.

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

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

1 голос
/ 11 марта 2012

Чтобы добавить к тому, что говорит Петер:

Тест OOME unit не будет зависеть от фактического исчерпания памяти. Вместо этого все запросы на загрузку файла должны реагировать соответствующим образом, когда загружаемый код генерирует OOME. Это то, что издевается / и т.д. предназначены для имитации поведения вне того, что тестируется. (То же самое для отсутствующих файлов / ошибок файловой структуры.)

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

Если загружаемый код нуждается в некоторой проверке поведения, когда файл слишком большой, я бы подумал о том, чтобы заглушить часть загрузки файла и заставить OOME, а не загружать гигантский файл, просто чтобы сэкономить время Чтобы подтвердить свою точку зрения, фактическое физическое поведение можно перенести в интеграционные тесты и, скажем, запустить на CI-сервере вне вашего собственного пульса TDD.

...