Создание сложных тестовых конфигураций с Red Deer

Это вторая из серии публикаций, посвященных новой среде тестирования с открытым исходным кодом «Красный олень» ( https://github.com/jboss-reddeer/reddeer ) для Eclipse. В предыдущем посте из этой серии мы представили Red Deer, узнали, как установить его в Eclipse, изучили некоторые его интересные функции, а также создали и запустили пример тестовой программы с нуля.

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

В первом посте из этой серии мы кратко рассмотрели реализацию классом требований Red Deer. В этом посте мы более подробно рассмотрим требования, в том числе то, как Red Deer поддерживает создание пользовательских требований.

Кейс для требований к автоматизированным испытаниям

Давайте начнем с определения контекста, почему тестовым программам нужны требования. Часто бывает так, что набор автоматических тестов запускается без присмотра, и все тесты не проходят, не из-за ошибки в тестируемом программном обеспечении, а из-за сломанной или неполной тестовой среды. Когда мы ссылаемся на «требование» к оленю, мы говорим о действиях, которые должны быть выполнены, или объектах, которые должны быть созданы, прежде чем можно будет запустить тест. Примерами этих требований являются определение учетной записи пользователя или создание и проверка подключения к базе данных.

Что отличает использование требований Red Deer от создания менее формального набора требований с помощью аннотации @BeforeClass, предоставляемой JUnit, так это то, что если требования не выполняются, то рассматриваемый тест не запускается. Это может сэкономить вам много времени на выполнение теста и время отладки ошибок теста.

Требования Red Deer реализованы в RedDeerSuite. Тест, использующий требования, должен выполняться с пакетом RedDeerSuite и аннотироваться с помощью @RunWith (RedDeerSuite.class)

OOTB Red Deer Требования

Как мы видели в первом посте этой серии, Red Deer в настоящее время предоставляет OOTB (готовые) предопределенные требования, которые позволяют вам очистить текущее рабочее пространство и открыть перспективу.

Использовать эти требования просто. Все, что вам нужно сделать, это добавить эти операторы импорта в свои тестовые программы Red Deer:

import org.jboss.reddeer.eclipse.ui.perspectives.JavaBrowsingPerspective;
import org.jboss.reddeer.requirements.cleanworkspace.CleanWorkspaceRequirement.CleanWorkspace;
import org.jboss.reddeer.requirements.openperspective.OpenPerspectiveRequirement.OpenPerspective;

И мы также должны добавить ссылку на org.jboss.reddeer.requirements в требуемый список комплектов в файле MANIFEST.MF нашего примера. И, наконец, добавьте эти аннотации в тестовую программу:

@CleanWorkspace
@OpenPerspective (JavaBrowsingPerspective.class)

Различные способы реализации новых требований к оленю

Red Deer поддерживает (4) пути реализации новых требований. Мы рассмотрим их в порядке их относительной сложности:

• Простые требования
• Требования с параметрами
• Требования с конфигурацией на основе свойств 
• Требования с пользовательской схемой 

Чтобы изучить, как Red Deer поддерживает реализацию новых требований, мы на самом деле создадим несколько новых требований в исходном коде Red Deer. Для этого нам нужно скачать копию исходного кода Red Deer. Чтобы выполнить эту загрузку, перейдите в нужный каталог и введите следующую команду:

git clone https://github.com/jboss-reddeer/reddeer.git

А затем импортируйте Red Deer в затмение в виде набора существующих проектов Maven:

Если вы перейдете на верхний уровень каталога, в который вы загрузили исходный код Red Deer, вы увидите это:

Что вы хотите сделать, это выбрать все проекты Red Deer. 

После того, как вы нажмете «Далее & gt;» ключ, Eclipse будет импортировать все пакеты Red Deer как проекты maven. (Это может занять несколько минут.)

Хорошо, теперь мы можем перейти к созданию новых требований. Мы начнем с самого простого из (4) типов, простого требования.

Реализация простого требования

Простое требование состоит из (2) частей: «исполняющего» класса, который предоставляет код, выполняемый при вызове требования, и аннотации, которая ссылается на этот исполняющий класс. В качестве иллюстрации давайте рассмотрим скелет «AdminUserRequirement», предоставляемый для загрузки Red Deer. Это требование предназначено в качестве примера для реализации полного требования, чтобы убедиться, что пользователь уровня администратора определен до того, как будет предпринята попытка запустить тест.

Исходный файл, который вы хотите найти:

/plugins/org.jboss.reddeer.examples/src/org/jboss/reddeer/junit/annotation/simple/AdminUserRequirement.java

Хотя это небольшой файл, это полный пример. Стоит рассмотреть это построчно:

package org.jboss.reddeer.junit.annotation.simple;  
import java.lang.annotation.ElementType;  
import java.lang.annotation.Retention;  
import java.lang.annotation.RetentionPolicy;  
import java.lang.annotation.Target;  
import org.jboss.reddeer.junit.requirement.Requirement;  
import org.jboss.reddeer.junit.annotation.simple.AdminUserRequirement.AdminUser;  
    
/**  
 * Admin user test requirement  
 * @author lucia jelinkova  
 *  
 */  
    
 public class AdminUserRequirement implements Requirement<AdminUser> {  
   
   @Retention(RetentionPolicy.RUNTIME)  
   @Target(ElementType.TYPE)  
    
   public @interface AdminUser {  
   }   
    
   public boolean canFulfill() {  
     // return true if you can connect to the database  
     return true;  
   }  
   
   public void fulfill() {  
     // create an admin user in the database if it does not exist yet  
   }  
   
   public void setDeclaration(AdminUser declaration) {  
     // no need to access the annotation  
   }  
}  

Важными элементами в этом файле являются: