Управляемые данными тесты с помощью jUnit

Question

Что вы используете для написания управляемых данными тестов в jUnit?

(Мое определение) управляемый данными тест - это тест, который считывает данные из какого-либо внешнего источника (файла, базы данных, ...), выполняет один тест на строку / файл / что угодно и отображает результаты в тесте бегун, как если бы у вас были отдельные тесты - результат каждого запуска отображается отдельно, а не в одном огромном агрегате.

Answer 1

В JUnit4 вы можете использовать Параметризованный testrunner для выполнения управляемых данными тестов.

Это не очень хорошо документировано, но основная идея состоит в том, чтобы создать статический метод (помеченный @Parameters), который возвращает массивы коллекций объектов. Каждый из этих массивов используется в качестве аргументов для конструктора тестового класса, а затем обычные тестовые методы могут быть запущены с использованием полей, установленных в конструкторе.

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

Answer 2

Здесь сияет TestNG со своим @DataSource. Это одна из причин, почему я предпочитаю это JUnit; остальные - это зависимости и параллельные многопоточные тесты.

Answer 3

Я использую базу данных в памяти, такую ​​как hsqldb , чтобы я мог либо предварительно заполнить базу данных набором данных «производственного стиля», либо начать с пустой базы данных hsqldb и заполнить это со строками, которые мне нужны для выполнения моего тестирования. Кроме того, я напишу свои тесты, используя JUnit и Mockito .

Answer 4

Я использую комбинацию dbUnit , jMock и jUnit 4. Затем вы можете запустить его как suite или отдельно

Answer 5

Вам лучше расширить TestCase с помощью DataDrivenTestCase, который соответствует вашим потребностям. Вот рабочий пример: http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html

В отличие от параметризованных тестов, он допускает хорошо названные тестовые случаи.

Answer 6

Хотя это довольно старая тема, я все еще думал о том, чтобы внести свой вклад. Я чувствую, что поддержка JUnit для тестирования, основанного на данных, менее и слишком недружественная. например чтобы использовать параметризованный, нам нужно написать наш конструктор. С Thener Runner у нас нет контроля над набором тестовых данных, которые передаются в метод теста.

Существуют и другие недостатки, указанные в этой серии постов: http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html

В настоящее время существует довольно приятное комплексное решение в виде EasyTest, которое представляет собой фреймворк, расширенный из JUnit и предназначенный для предоставления пользователям множества функций. Его основной задачей является выполнение Data Driven Testing с использованием JUnit, хотя от вас больше не требуется зависеть от JUnit. Вот проект GitHub для ссылки: https://github.com/anujgandharv/easytest

Если кто-то заинтересован поделиться своими мыслями / кодом / предложениями, то сейчас самое время. Вы можете просто зайти в репозиторий github и создать проблемы.

Answer 7

Я с @ DroidIn.net, это именно то, что я делаю, однако, чтобы ответить на ваш вопрос буквально "и отображает результаты в тестовом средстве, как если бы у вас были отдельные тесты", вы должны взглянуть на JUnit4 Параметризованный бегун. DBUnit этого не делает. Если вам нужно сделать много, честно говоря, TestNG более гибок, но вы можете сделать это в JUnit.

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

Answer 8

Некоторые тесты пригодны для интерфейса.

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

Answer 9

В настоящее время у нас есть реквизит с нашими идентификационными номерами. Это ужасно хрупко, но легко что-то сделать. Наш план состоит в том, чтобы изначально эти ID-номера были переопределены свойствами -D в наших сборках ant.

В нашей среде используется устаревшая БД с ужасно переплетенными данными, которые не загружаются перед запуском (например, dbUnit). В конце концов мы бы хотели попасть туда, где модульный тест запросил бы БД, чтобы найти идентификатор с тестируемым свойством, а затем использовал этот идентификатор в модульном тесте. Это было бы медленно и более правильно называется интеграционным тестированием, а не «модульным тестированием», но мы будем проводить тестирование на реальных данных, чтобы избежать ситуации, когда наше приложение отлично работает с тестовыми данными, но не с реальными данными.

Answer 10

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