Управляемые данными тесты с jUnit
Вы должны создать один класс контекста.
public class Context {
private final static Context instance = new Context();
public static Context getInstance() {
return instance;
}
private Connection con;
public void setConnection(Connection con)
{
this.con=con;
}
public Connection getConnection() {
return con;
}
private TabRoughController tabRough;
public void setTabRough(TabRoughController tabRough) {
this.tabRough=tabRough;
}
public TabRoughController getTabRough() {
return tabRough;
}
}
Вам нужно просто установить экземпляр контроллера при инициализации с помощью
Context.getInstance().setTabRough(this);
, и вы можете использовать его из всего приложение только с помощью
TabRoughController cont=Context.getInstance().getTabRough();
Теперь вы можете передать параметр любому контроллеру из всего приложения.
10 ответов
В JUnit4 вы можете использовать параметризованный testrunner для выполнения управляемых данными тестов.
Это не очень хорошо задокументировано, но основная идея состоит в том, чтобы создать статический метод (с пометкой @Parameters), который возвращает массивы Collection of Object. Каждый из этих массивов используется в качестве аргументов для конструктора тестового класса, а затем обычные тестовые методы могут быть запущены с использованием полей, установленных в конструкторе.
Вы можете написать код для чтения и анализа внешнего текстового файла в методе @Parameters (или получить данные из другого внешнего источника), а затем вы сможете добавлять новые тесты, редактируя этот файл без перекомпиляции тестов. .
Я использую базу данных в памяти, такую как hsqldb , чтобы я мог либо предварительно заполнить базу данных набором данных «производственного стиля», либо начать с пустой базы данных hsqldb и заполнить это со строками, которые мне нужны для выполнения моего тестирования. Кроме того, я напишу свои тесты, используя JUnit и Mockito .
Я использую комбинацию dbUnit , jMock и jUnit 4. Затем вы можете запустить его как suite или отдельно
Вам лучше расширить TestCase с помощью «DataDrivenTestCase», который соответствует вашим потребностям. Вот рабочий пример: http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html
В отличие от параметризованных тестов, он позволяет красиво именованные тесты.
Несмотря на то, что это довольно старая тема, я все еще думал о том, чтобы внести свой вклад. Я чувствую, что поддержка JUnit для тестирования, основанного на данных, менее и слишком недружественная. например чтобы использовать параметризованный, нам нужно написать наш конструктор. С Theory 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 и создать проблемы.
Некоторые тесты пригодны для интерфейса.
Если чтение базы данных / файла извлекается с помощью интерфейсного вызова, тогда просто получите свой модульный тест для реализации интерфейса, и класс модульного теста может вернуть любые данные, которые вы хотите.
В настоящее время у нас есть реквизит с нашими идентификационными номерами. Это ужасно хрупко, но легко что-то сделать. Наш план состоит в том, чтобы изначально эти ID-номера были переопределены свойствами -D в наших сборках ant.
В нашей среде используется устаревшая БД с ужасно переплетенными данными, которые не загружаются перед запуском (например, dbUnit). В конце концов мы бы хотели попасть туда, где модульный тест запросил бы у БД идентификатор с тестируемым свойством, а затем использовал этот идентификатор в модульном тесте. Он будет медленным и более правильно называется интеграционным тестированием, а не «модульным тестированием», но мы будем тестировать на реальных данных, чтобы избежать ситуации, когда наше приложение будет отлично работать с тестовыми данными, но не с реальными данными.
Я использую @ DroidIn.net, это именно то, что я делаю, однако, чтобы ответить на ваш вопрос буквально «и отображает результаты в средстве выполнения тестов, как если бы у вас были отдельные тесты», вам нужно посмотреть на параметризованный бегун JUnit4. DBUnit этого не делает. Если вам приходится делать много этого, честно говоря, TestNG более гибок, но вы абсолютно можете сделать это в JUnit.
Вы также можете посмотреть бегун JUnit Theories, но я помню, что он не очень хорош для наборы данных, управляемые данными, что имеет смысл, поскольку JUnit не предназначен для работы с большими объемами внешних данных.
Обычно тесты, управляемые данными, используют небольшой тестируемый компонент для обработки данных. (Объект чтения файла или имитирующие объекты). Для баз данных и ресурсов вне приложения имитация используется для имитации других систем. (Веб-сервисы, базы данных и т. Д.). Обычно я вижу, что есть файлы внешних данных, которые обрабатывают данные и вывод. Таким образом, файл данных может быть добавлен в VCS.
Вот где блистает TestNG с его @DataSource. Это одна из причин, почему я предпочитаю его JUnit; остальные - зависимости и параллельные многопоточные тесты.