Портрет автоматизатора

 

Some obvious ideas about back-end and BD autotests.

Some "C.O"-like ideas about back-end and BigData(ETL) test automation:
1. Conceptually the back-end testing approach may look like:

2. In case of BigData ETL(Extract-Transform-Load) application:

There is no huge difference but:
а. your tests interact with some schedulers and other "auxiliarry" tools now.
b. there is no direct response from the system-under-test(requests-response-check turns into request for launch-wait-check output data).
c. test data approach (in terms of libraries to use) - is quite similar.
d. since there is no direct interaction with SUT there are more libraries in your test automation project.
e. Output data checks often contain "does look like truth?"-like checks.

Мысли вслух о разнице между автотестами на ПИП и для Большеданных приложений

Просто наблюдение "внимательного индейца Джо":
1. На уровне "квадратиков" подход к авто-тестированию тылового междумордия( ПИП) выглядит так:

2. А вот в случае всяких большеданных приложений типа "Взять-Преобразовать-Выдать":

Великой разницы нет, почти те же самые тесты на междумордий, однако:
а. работать приходится не с самим приложением, а с некими дополнительными приспособами которые запускают уже само приложение и т.д.
б. непосредственного ответа от тестируемого приложения может и не быть ("запрос - ответ - проверка что там в ответе пришло" меняется на "запрос на запуск - ожидание - проверка данных в выдаче")
в. работа со входными-выходными данными (на уровне библиотек и вызовов) - практически такая же.
г. за счёт работы через "посредников" количество дополнительных библиотек в проекте возрастает.
д. Сами проверки выхлопа часто включают в себя "похоже ли на правду" ибо при больших объёмах жёстко сравнивать вход-выход может быть ооооочень дорого.

О работе с требованиями и общности ИТ с остальным миром.

Перекрёсток, нерегулируемый. Его(перекрёсток) переделывают в регулируемый, Канавы, знаки, светофоры... . Пешеходный переход на этом перекрёстке и пятеро(5-ро) мужиков машут руками, голосят, споря где/как/что тут  копать/штробить/цементировать. И тут один из них выдаёт робкую фразу “А как у нас по проекту должно быть?“. 
Оказывается не только лишь в ИТ так, не только лишь... .

How-to adapt test Data-pool.

 There is such a thing  - Test Data-Pool. Seems to be usefull and there are usage examples but still it is not absolutely clear how-to start.

Given there are tests based on Java+testNG+maven + something else. Let's start:

1. Add maven dependency

 com.griddynamics.qa.datapool

 data-pool

 1.0.1

Specify actual version of course.

2. Greate/find entities package. Add a new entity class

package ru.test.automation.entities;

import com.griddynamics.qa.datapool.DataTypeFactory;

import com.griddynamics.qa.datapool.datatype.IDataType;

/**

 * Represents a BitBucketUser entity.

 */

public interface BitBucketUser extends IDataType {

    static BitBucketUser newUser(){

        return DataTypeFactory.create(BitBucketUser.class);

    }

    Integer getId();

    String getLogin();

    String getPassword();

}

Field set could be different.

3. Greate/find  /resources/data directory and add the data-file

!DataTypeKey 'interface ru.test.automation.entities.BitBucketUser':

- !IDataType {id: 1, login: Uzvr_Odin, password: Klu4slovo}

- !IDataType {id: 2, login: uzvr-Dva, password: derParrollen}

- !IDataType {id: 3, login: uzvr-Tri, password: AEtoKto?}

Let's name the file as ls.yml

4. Highly likely there is a BaseTest so add the following to it

import ru.test.automation.entities.BitBucketUser;

import com.griddynamics.qa.datapool.DataPool;

import static com.griddynamics.qa.datapool.FilterCriterion.by;

import static com.griddynamics.qa.datapool.matchers.StandardMatchers.CONTAINS;

...

@BeforeSuite

protected void loadData() {

    ClassLoader classLoader = getClass().getClassLoader();

    DataPool.load(Paths.get(classLoader.getResource("data/ls.yml").getPath()));

    // TODO: Switch to the approach below when Data-pool 1.0.2 is released.// DataPool.load("data/ls.yml");

}

//TODO: Think about moving into a separate data-access class.

protected BitBucketUser getUserByLogin(String partOfLoginName) {

    return DataPool.find(BitBucketUser.class, by("login", CONTAINS, partOfLoginName)).get(0);

}

5. And finally, within a test

BitBucketUser usr = getUserByLogin("Uzvr_Odin");

loginPage().login(usr.getLogin(), usr.getPassword());

Как перестать думать и прикрутить ДатаПул к тестам.

Есть вот такая штука - ДатаПул. Вроде бы полезная и примеры есть прямо в местележания, но как-то непонятно с чего начать прикручивать и как использовать.

Допустим есть тесты. Все из себя на Джаве + ТестНГ + мавен + что-нибудь ещё. Приступим:
1. Добавить зависимость
  

 com.griddynamics.qa.datapool

 data-pool

 1.0.1

Версию конечно же нужно проставить актуальную на текущий момент.

2. Создать/найти пакет entities (или что-то подобное) . Допуская, что нам нужны данные тестовых пользователей добавляем что-то вроде

package ru.test.automation.entities;

import com.griddynamics.qa.datapool.DataTypeFactory;

import com.griddynamics.qa.datapool.datatype.IDataType;

/**

 * Represents a BitBucketUser entity.

 */

public interface BitBucketUser extends IDataType {

    static BitBucketUser newUser(){

        return DataTypeFactory.create(BitBucketUser.class);

    }

    Integer getId();

    String getLogin();

    String getPassword();

}

Поля у объекта конечно же могут быть и не такими.

3. Создать/найти директорию /resources/data и добавить туда собственно файл с данными

!DataTypeKey 'interface ru.test.automation.entities.BitBucketUser':

- !IDataType {id: 1, login: Uzvr_Odin, password: Klu4slovo}

- !IDataType {id: 2, login: uzvr-Dva, password: derParrollen}

- !IDataType {id: 3, login: uzvr-Tri, password: AEtoKto?}

Пусть этот файл зовётся ls.yml

4. Наверняка в тестах есть какой-нибудь BaseTest, туда можно-нужно-стоит добавить

import ru.test.automation.entities.BitBucketUser;

import com.griddynamics.qa.datapool.DataPool;

import static com.griddynamics.qa.datapool.FilterCriterion.by;

import static com.griddynamics.qa.datapool.matchers.StandardMatchers.CONTAINS;

...

@BeforeSuite

protected void loadData() {

    ClassLoader classLoader = getClass().getClassLoader();

    DataPool.load(Paths.get(classLoader.getResource("data/ls.yml").getPath()));

    // TODO: Switch to the approach below when Data-pool 1.0.2 is released.// DataPool.load("data/ls.yml");

}

//TODO: Think about moving into a separate data-access class.

protected BitBucketUser getUserByLogin(String partOfLoginName) {

    return DataPool.find(BitBucketUser.class, by("login", CONTAINS, partOfLoginName)).get(0);

}

5. И наконец! В нужном месте, в нужном тесте можно сделать так

BitBucketUser usr = getUserByLogin("Uzvr_Odin");

loginPage().login(usr.getLogin(), usr.getPassword());

How do I get list of tests steps without executing the tests?

Given:
Auto-tests(Java + TestNG + Allure).
Steps (@Step) - return nothing, all are void.
There are data-driven tests.

The task:
a. Do not execute the steps;
b. Get list of all tests;
c. For each test - get list of steps with parameters' values.

A straightforward solution:
1. Use aspects (AspectJ);
2. Link @Around to ("anyMethod() && withStepAnnotation()");
3. Use org.aspectj.lang.reflect to get steps annotations and parameters names and values;
4. Inside the @Around advice - get the information needed but do not execute intercepted methods, just return null.

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.aspectj.lang.reflect.MethodSignature;
import org.testng.ITestResult;
import org.testng.Reporter;
import ru.yandex.qatools.allure.annotations.Step;
...
@Pointcut("@annotation(ru.yandex.qatools.allure.annotations.Step)")
public void withStepAnnotation() {}

@Pointcut("execution( (..))")
public void anyMethod() {}
...
@Around("anyMethod() && withStepAnnotation()")
public Object logTestStepDataAndSkipExecution(ProceedingJoinPoint point) throws Throwable {
    if (isDryRun) {
        MethodSignature methodSignature = MethodSignature.class.cast(point.getSignature());

        String paramNamesAndValues = getParamNamesAndValues(point, methodSignature);
        
        Util.addStepDescriptionEntry(createTitle(point) + " | " + paramNamesAndValues);

        return null;
    } else {
        return point.proceed();
    }
}
...
private String getParamNamesAndValues(JoinPoint point, MethodSignature methodSignature) {
    String[] paramNames = methodSignature.getParameterNames();
    Object[] paramValues = point.getArgs();
    StringBuilder sb = new StringBuilder();
    for (int i=0; i< paramNames.length; i++) {
        sb.append(paramNames[i]).append("=").append(paramValues[i]).append(" | ");
    }
    return sb.toString();
}


Links:
Mainly inspired by  https://www.yegor256.com/2014/06/01/aop-aspectj-java-method-logging.html
Generally - https://duckduckgo.com/?q=Java+AspectJ+examples&t=ffab&ia=web

Как получить список шагов внутри теста без выполнения самих шагов?

Дано:
Авто-тесты(Джава + ТестНГ + Аллюр).
Шаги (@Step) - ничего не возвращают, все войд.
Среди тестов встречаются параметризированные.

Странная задача:
а. Сами тесты (шаги) не выполнять;
б. Получить список всех тестов;
в. Для каждого теста - получить список шагов вместе с параметрами.

Не менее странное влобное решение:
1. Использовать аспекты;
2. Вешать  @Around на ("anyMethod() && withStepAnnotation()");
3. Использовать org.aspectj.lang.reflect для вытаскивания аннотаций и названий/значений параметров;
4. Внутри совета @Around - вытягивать нужную информацию, а сам аллюровский шаг не запускать, возвращать налл.

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.aspectj.lang.reflect.MethodSignature;
import org.testng.ITestResult;
import org.testng.Reporter;
import ru.yandex.qatools.allure.annotations.Step;
...
@Pointcut("@annotation(ru.yandex.qatools.allure.annotations.Step)")
public void withStepAnnotation() {}

@Pointcut("execution( (..))")
public void anyMethod() {}
...
@Around("anyMethod() && withStepAnnotation()")
public Object logTestStepDataAndSkipExecution(ProceedingJoinPoint point) throws Throwable {
    if (isDryRun) {
        MethodSignature methodSignature = MethodSignature.class.cast(point.getSignature());

        String paramNamesAndValues = getParamNamesAndValues(point, methodSignature);
        
        Util.addStepDescriptionEntry(createTitle(point) + " | " + paramNamesAndValues);

        return null;
    } else {
        return point.proceed();
    }
}
...
private String getParamNamesAndValues(JoinPoint point, MethodSignature methodSignature) {
    String[] paramNames = methodSignature.getParameterNames();
    Object[] paramValues = point.getArgs();
    StringBuilder sb = new StringBuilder();
    for (int i=0; i< paramNames.length; i++) {
        sb.append(paramNames[i]).append("=").append(paramValues[i]).append(" | ");
    }
    return sb.toString();
}


Ссылки:
Основная доля вдохновения почерпнута из https://www.yegor256.com/2014/06/01/aop-aspectj-java-method-logging.html
А в целом - https://duckduckgo.com/?q=Java+AspectJ+examples&t=ffab&ia=web

О статусе релиза.

- What is the release status?
- "We have enough fails for now"(c).

Как оно, начинать.

 Начать автоматизировать/писать тесты и вообще начать похоже на езду на велосипеде. Вроде всё понятно и со стороны прелестно, а вот когда пробуешь сам, то просто не понимаешь как оно вообще возможно сохранить равновесие и куда-то ещё и ехать. И никакие тренинги, книжки, мастер-классы и прочее и прочее не  сделают за тебя тот самый первый толчок ногой и не проедут первые виляющие метры. Только сам, только набивая шишки.

И снова о локаторах.

Отличный локатор элемента.