В предыдущем уроке мы начали с представления иерархии проекта-образца и различных компонентов фреймворка. Мы также обсудили источник данных – “excels”, используемый для хранения тестовых данных и манипуляций с ними в excel. Мы также обсудили новые стратегии и ресурсы для развития нашего фреймворка.
Сейчас мы переходим к продвинутым темам в этой серии обучения Selenium. На этом занятии мы воспользуемся возможностью обсудить две важные концепции, которые играют важную роль в развитии фреймворка. Мы обсудим концепцию Generics и аспекты повторного использования. Мы также обсудим создание и значение тестового пакета.
Для лучшего понимания мы будем сопровождать концепции соответствующими примерами и образцами кода.
Содержание:
Дженерики
Согласно буквальному понятию, дженерик – это то, что может служить описанием целой группы или классов.
При автоматизации приложений мы сталкиваемся с различными конечными сценариями. Конечный сценарий может состоять из нескольких тривиальных функций. Таким образом, многие из этих функций могут выступать в качестве общих функций для нескольких тестовых сценариев с небольшими или почти без изменений.
Следовательно, рекомендуется создать общий класс, состоящий из методов, которые могут быть заявлены как общие и могут использоваться совместно в нескольких тестовых сценариях, вместо того, чтобы реализовывать один и тот же код снова и снова для нескольких тестовых сценариев.
Обратите внимание, что дженерики также привносят силу повторного использования в наш фреймворк. Многократное использование исключительно сокращает время, затрачиваемое на код, ошибки, баги, сопровождение и т.д.
Типы дженериков
1. Специфические для приложения
Скудная функциональность, принадлежащая тестируемому приложению, может стать частью генериков Application Specific. Возьмем, к примеру, функциональность входа в систему. Логин – одна из таких функций, которая может быть фрагментом почти всех тестовых скриптов. Таким образом, вместо того, чтобы заново писать код входа в систему в тестовых сценариях, мы создадим общий метод в классе generic и будем вызывать его везде, где это необходимо.
2. Специфические для фреймворка
Помимо общих методов, специфичных для конкретного приложения, у нас могут быть общие методы, которые не имеют прямого отношения к тестируемому приложению, но являются частью выбранного фреймворка. Рассмотрим функциональность чтения Excel, когда мы используем Test Data Driven Framework. Было бы бессмысленно писать код для чтения Excel снова и снова во всех тестовых сценариях. Поэтому мы вводим код один раз в общий класс и вызываем его всякий раз, когда это необходимо.
Создание общего класса
Пользователь имеет возможность создавать столько общих классов, сколько он/она пожелает, основываясь на модульности.
Давайте разберемся в концепции дженерика, создав один из них.
Шаг 1: Создайте новый java-класс “CommonMethods.java”, который будет действовать как общий класс, состоящий из общих методов, предпочтительно в пакете, отличном от того, где находятся тестовые сценарии.
Шаг 2: Следующим шагом будет копирование и вставка приведенного ниже кода в общий класс “CommonMethods.java”. Ряд общих методов может быть реализован внутри периферии этого класса. Ниже приведен фрагмент кода для функциональности входа в систему.
/**
* Login the Test application
*
* @param username
* @param password
*/
public void login(String username, String password) {
try {
// Enter User Name
WebElement userName = driver.findElement(By.id("loginID"));
userName.clear();
userName.sendKeys(username);
// Enter Password
WebElement passWord = driver.findElement(By.id("Password"));
passWord.clear();
passWord.sendKeys(password);
// Click on the Sign In Button
WebElement signin = driver.findElement(By.id("SignIn_button"));
signin.click();
driver.manage().window().maximize();
} catch (Exception e) {
e.printStackTrace();
}
} Обратите внимание, что вышеупомянутый метод является параметризованным методом. Таким образом, один и тот же метод может быть использован для тестирования функциональности входа в систему с различными наборами тестовых данных.
Шаг 3: Следующим шагом будет вызов общего метода в тестовом сценарии. Этот процесс состоит из двух шагов. Сначала мы создаем экземпляр общего класса в тестовом классе, а затем вызываем общий метод на созданном экземпляре, передавая необходимые аргументы. В приведенном ниже фрагменте кода мы создали экземпляр класса “TestScript1.java” и вызвали метод login() для входа в приложение.
// Create Object of the generic class toolsObj = new Tools(); // Login the test application by calling the common method preTestObj.login(“username”, “password”);
Обратите внимание, что приведенный выше код может быть размещен в любом месте класса test. Пользователь может поместить код в метод setup () или в метод test ().
Набор тестов
Набор тестов представляет собой набор из нескольких тестовых сценариев, сгруппированных вместе для выполнения. Таким образом, тестовый набор выполняет определенное количество заданных тестовых сценариев без посторонней помощи. Набор тестов имеет возможность указывать тестовые сценарии, которые будут выполняться автоматически; все, что требуется от пользователя, это отметить запись для каждого отдельного тестового сценария в наборе тестов. Запись должна быть “именем класса” тестового сценария с расширением “.class” или просто скомпилированной формой нашего java-класса.
Ниже приведен пример тестового набора, созданного на языке java. Обратите внимание, что тестовый пакет – это класс на основе java, который принадлежит к семейству JUnit. Таким образом, вы можете встретить в коде несколько аннотаций JUnit.
Сниппет кода
package com.axway.webliv.tests;
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.runner.JUnitCore;
import org.junit.runner.Result;
import org.junit.runner.RunWith;
import org.junit.runner.notification.Failure;
import org.junit.runners.Suite;
import com.axway.webliv.tests.MetaData.*;
@RunWith(Suite.class)
@Suite.SuiteClasses({
ChangeStatusBinarySphereTest.class,
ChangeStatusRestrictionTest.class,
ChangeStatusDocSphereTest.class,
})
public class TestSuite {
/**
* Setup method to set system properties
*/
@BeforeClass
public static void Setup() {
}
/**
* @param args
*/
public static void main(String[] args) {
Result result = JUnitCore.runClasses(TestSuite.class);
System.out.println("TEST CASES RUN: " + result.getRunCount());
System.out.println("TEST CASES FAILED: " + result.getFailureCount());
for (Failure failure : result.getFailures()) {
System.out.println("\nTEST NAME: " + failure.getTestHeader());
System.out.println("\nERROR: " + failure.getMessage() + "\n");
System.out.println(failure.getTrace());
System.exit(1);
}
}
/**
* Report test results
*/
@AfterClass
public static void TearDown() {
}
} Обзор кода
Набор тестов – это не что иное, как простой класс JUnit с методами setup() и teardown(), о которых мы подробно рассказывали в предыдущих уроках. Единственное существенное отличие заключается в его способности выполнять более одного тестового сценария за один раз.
Утверждения импорта
import org.junit.AfterClass; import org.junit.BeforeClass; import org.junit.runner.JUnitCore; import org.junit.runner.Result; import org.junit.runner.RunWith; import org.junit.runner.notification.Failure; import org.junit.runners.Suite;
Приведенные выше утверждения импорта встраиваются в класс, чтобы иметь возможность использовать различные аннотации, предоставляемые JUnit.
import org.junit.runner.JUnitCore; import org.junit.runner.RunWith; import org.junit.runners.Suite;
Приведенные выше утверждения имеют базовую архитектуру для выполнения набора тестов, состоящего из нескольких тестовых классов.
import org.junit.runner.Result;
Оператор импорта позволяет пользователю хранить статусы выполнения теста и манипуляции с ними.
import org.junit.AfterClass; import org.junit.BeforeClass;
Эти утверждения импорта используются для определения и аннотирования методов setup() и teardown(). Метод setup(), аннотированный BeforeClass, предписывает управляющей программе выполнять метод перед каждым выполнением тестового сценария. Как и метод setup(), метод teardown(), аннотированный AfterClass, указывает управляющей программе выполнить метод после каждого выполнения тестового сценария.
Class Entry
@RunWith(Suite.<strong>class</strong>)
@Suite.SuiteClasses({
ChangeStatusBinarySphereTest.<strong>class</strong>,
ChangeStatusRestrictionTest.<strong>class</strong>,
ChangeStatusDocSphereTest.<strong>class</strong>,
}) Выполнение – main ()
public static void main(String[] args) {
Result result = JUnitCore.runClasses(TestSuite.class);
System.out.println("TEST CASES RUN: " + result.getRunCount());
System.out.println("TEST CASES FAILED: " + result.getFailureCount());
for (Failure failure : result.getFailures()) {
System.out.println("\nTEST NAME: " + failure.getTestHeader());
System.out.println("\nERROR: " + failure.getMessage() + "\n");
System.out.println(failure.getTrace());
System.exit(1);
}
} Эта часть кода посвящена выполнению программы. Выполнение программы всегда начинается с main().
Метод runClasses класса JUnitCore используется для выполнения набора тестов. Класс “Result class” и его методы используются для определения статуса выполнения в терминах пройденных и проваленных тестовых случаев.
Таким образом, пользователь имеет возможность играть с классом тестового набора, чтобы удовлетворить свои требования.
Заключение
В этом руководстве мы попытались познакомить вас с концепцией дженериков и общих методов. Мы также обсудили преимущества, которые дают общие методы, такие как возможность повторного использования. Мы также поделились практическими подходами к созданию дженериков и их доступности.
Вот основные положения этой статьи:
- Дженерик – это то, что может служить описанием целой группы или классов. В нашем фреймворке дженерик – это класс, состоящий исключительно из методов, которые могут быть общими для нескольких тестовых классов.
- Дженерики можно разделить на две категории:
- специфические для приложения
- специфические для фреймворка
- Для работы в качестве дженерика можно создать простой java-класс. Ряд общих методов может быть реализован внутри класса generic. Эти методы могут быть параметризованными методами.
- Доступ к общим методам можно получить, вызывая их на экземпляре класса generic в тестовых сценариях.
- Набор тестов – это несколько тестовых сценариев, сгруппированных вместе для выполнения. Таким образом, тестовый набор выполняет определенное количество заданных тестовых сценариев без посторонней помощи.
- Набор тестов – это не что иное, как простой класс JUnit, имеющий методы setup() и teardown(), о которых мы подробно рассказывали в предыдущих уроках. Единственное существенное отличие заключается в том, что он может выполнять более одного тестового сценария за один раз.
Перевод статьи «Creating Generics And Testsuites».