Управляемые данными тесты с jUnit
Что вы используете для написания тестов на основе данных в jUnit?
(мое определение) управляемый данными тест-это тест, который считывает данные из внешнего источника (файла, базы данных ...), выполняет один тест на строку / файл / что угодно и отображает результаты в тестовом бегуне, как если бы у вас были отдельные тесты - результат каждого запуска отображается отдельно, а не в одной огромной совокупности.
10 ответов
в JUnit4 вы можете использовать параметризованные testrunner делать данные тесты гонят.
это не очень хорошо документировано, но основная идея заключается в создании статического метода (аннотированного @Parameters), который возвращает коллекцию массивов объектов. Каждый из этих массивов используется в качестве аргументов конструктора тестового класса, а затем с помощью полей, заданных в конструкторе, можно запускать обычные методы тестирования.
вы можете написать код для чтения и анализа внешнего текстовый файл в @Parameters метод (или получить данные из другого внешнего источника), а затем вы сможете добавить новые тесты, отредактировав этот файл без перекомпиляции тестов.
здесь TestNG с его @DataSource сияет. Это одна из причин, почему я предпочитаю его JUnit; другие-зависимости и параллельные тесты.
Я использую базу данных в памяти, такую как hsqldb чтобы я мог либо предварительно заполнить базу данных набором данных "производственного стиля", либо начать с пустой базы данных hsqldb и заполнить ее строками, которые мне нужны для выполнения моего тестирования. Кроме того, я напишу свои тесты, используя JUnit и Mockito.
Я использую комбинацию д. Банкрофт, jMock и jUnit 4. Затем вы можете запустить его как suite или отдельно
вам лучше расширить TestCase с помощью "DataDrivenTestCase", который соответствует вашим потребностям. Вот рабочий пример: http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html
В отличие от параметризованных тестов, он позволяет красиво называть тестовые случаи.
Я с @DroidIn.net, это именно то, что я делаю, однако, чтобы ответить на ваш вопрос буквально "и отображает результаты в тестовом бегуне, как если бы у вас были отдельные тесты", вы должны посмотреть на параметризованный бегун JUnit4. Д. Банкрофт не делает этого. Если вам нужно сделать много этого, честно говоря, TestNG более гибкий, но вы можете абсолютно сделать это в JUnit.
вы также можете посмотреть на JUnit Theories runner, но мое воспоминание о том, что это не очень хорошо для данных наборы данных, что имеет смысл, потому что JUnit не работает с большими объемами внешних данных.
хотя это довольно старая тема, я все еще думал о том, чтобы внести свою долю. Я чувствую, что поддержка JUnit для тестирования на основе данных меньше и слишком недружелюбна. для EG. чтобы использовать параметризованный, нам нужно написать наш конструктор. С помощью Theories runner мы не контролируем набор тестовых данных, который передается методу тестирования.
есть больше недостатков, как указано в этой серии сообщений в блоге: http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html
в настоящее время существует комплексное решение, которое довольно хорошо сочетается в форме EasyTest, который является платформой, расширенной из JUnit и предназначен для предоставления большой функциональности своим пользователям. Его основной целью является выполнение тестирования данных с помощью JUnit, хотя вам больше не нужно зависеть от JUnit. Вот проект github для refernece: https://github.com/anujgandharv/easytest
Если кто-то заинтересован в том, чтобы внести свои мысли/код/предложения, то это время. Вы можете просто перейти в репозиторий github и создать проблемы.
обычно тесты, управляемые данными, используют небольшой тестируемый компонент для обработки данных. (Объект чтения файлов или макет объектов) для баз данных и ресурсов за пределами приложения mocks используются для сравнения других систем. (Веб-службы, базы данных и т. д.). Обычно я вижу, что есть внешние файлы данных, которые обрабатывают данные и выходные данные. Таким образом, файл данных может быть добавлен в VCS.
в настоящее время у нас есть файл реквизита с нашими идентификационными номерами. Это ужасно хрупкий, но легко получить что-то происходит. В наших планах изначально имеют эти идентификаторы переопределяемыми -D свойства в нашем муравей строит.
наша среда использует устаревшую БД с ужасно переплетенными данными, которые не загружаются перед запуском (например, dbUnit). В конце концов, мы хотели бы добраться до того, где модульный тест будет запрашивать БД, чтобы найти идентификатор с тестируемым свойством, а затем использовать этот идентификатор в модульный тест. Это было бы медленным и более правильно называется интеграционным тестированием, а не" модульным тестированием", но мы будем тестировать реальные данные, чтобы избежать ситуации, когда наше приложение отлично работает с тестовыми данными, но терпит неудачу с реальными данными.
некоторые тесты будут поддаваться управлению интерфейсом.
Если чтение базы данных/файла извлекается вызовом интерфейса, просто получите модульный тест для реализации интерфейса, и класс модульного теста может возвращать любые данные, которые вы хотите.