Con este artículo, continuamos una serie de publicaciones sobre cómo automatizamos el proceso de pruebas manuales (en lo sucesivo denominadas pruebas automáticas) de un gran sistema de información (en adelante, Sistemas) en uno de los principales proyectos de LANIT y lo que surgió de él.

¿Cómo organizar eficientemente una jerarquía de clases? ¿Cómo distribuir paquetes en el árbol del proyecto? ¿Cómo asegurarse de olvidar los conflictos de fusión con un equipo de 10 personas? Estos problemas siempre están al comienzo de un nuevo desarrollo y nunca tienen suficiente tiempo.

Fuente

En este artículo, describimos la estructura de clases y la organización del código, lo que nos permitió desarrollar con poco esfuerzo más de mil y medio pruebas de IU de extremo a extremo basadas en Junit y Selenium para un gran sistema de importancia federal. Además, lo respaldamos con éxito y perfeccionamos constantemente los escenarios existentes.

Aquí puede encontrar una descripción práctica de la estructura jerárquica de las clases base de autotest, el desglose del proyecto de acuerdo con el modelo funcional java-packages y plantillas de muestra de clases reales.

El artículo será útil para todos los desarrolladores que desarrollen autoevaluaciones basadas en Selenium.

Este artículo es parte de una publicación general en la que describimos cómo un pequeño equipo construyó el proceso de automatización de pruebas de IU y desarrolló un marco basado en Junit y Selenium para esto.

Partes anteriores:

• Parte 1. Organizacional y gerencial. ¿Por qué necesitamos automatización? Organización del proceso de desarrollo y gestión. Organización de uso
• Parte 2. Técnica. Arquitectura y pila técnica. Detalles de implementación y sorpresas técnicas.

Implementación de clase base para todas las pruebas y JUnit RuleChain

El concepto de desarrollo de pruebas automáticas, como se muestra en el artículo anterior ( Parte 2. Técnica. Arquitectura y pila técnica. Detalles de implementación y sorpresas técnicas ), se basa en la idea de un marco en el que se proporciona un conjunto de funciones del sistema para todas las pruebas automáticas: se integran perfectamente y permiten a los desarrolladores Las pruebas automáticas se centran en cuestiones específicas de la implementación empresarial de las clases de prueba.

El marco incluye los siguientes bloques funcionales:

• Reglas: inicialización y finalización de componentes de infraestructura de prueba como inicialización de WebDriver y recepción de una prueba de video. Descrito con más detalle a continuación;
• WebDriverHandlers: funciones de ayuda para trabajar con un controlador web, como ejecutar Java Script o acceder a los registros del navegador. Implementado como un conjunto de métodos estáticos sin estado;
• WebElements es una biblioteca de elementos web típicos o sus grupos, que contiene la funcionalidad de función cruzada requerida y el comportamiento típico. En nuestro caso, esta funcionalidad incluye una posible verificación de la finalización de operaciones asincrónicas en el lado del navegador web. Implementado como extensiones de elementos web de las bibliotecas Selenium y Selenide.

Inicialización del entorno de prueba. Reglas

La clase clave para todas las clases de prueba es BaseTest, de la cual se heredan todas las clases de prueba. La clase BaseTest define el "corredor" de pruebas de Junit y el RuleChain utilizado, como se muestra a continuación. El acceso desde las clases de prueba aplicadas a las funciones proporcionadas por las clases de reglas se proporciona mediante los métodos estáticos de las clases de reglas.

El código de muestra de BaseTest se presenta en el siguiente cuadro.

@RunWith(FilterTestRunner.class) public class BaseTest { private TemporaryFolder downloadDirRule                                                                  = new TemporaryFolder(getSomething().getWorkingDir());      @Rule     public RuleChain rules = RuleChain             .outerRule(new Timeout(TimeoutEnum.GLOBAL_TEST_TIMEOUT.value(),                                                                       TimeUnit.SECONDS))             .around(new TestLogger())             .around(new StandStateChecker())             .around(new WaitForAngularCreator())             .around(downloadDirRule)             .around(new DownloaderCreator(downloadDirRule))             .around(new EnvironmentSaver())             .around(new SessionVideoHandler())             .around(new DriverCreator(downloadDirRule))             .around(new BrowserLogCatcher(downloadDirRule))             .around(new ScreenShooter())             .around(new AttachmentFileSaver())             .around(new FailClassifier())             .around(new PendingRequestsCatcher());     //            final protected SomeObject getSomething() {         return Something.getData();    }    … } 

FilterTestRunner.class : una extensión de BlockJUnit4ClassRunner, proporciona el filtrado de la composición de las pruebas ejecutables basadas en expresiones regulares por el valor de la anotación especial Filter (value = "some_string_and_tag"). La implementación se da a continuación.

org.junit.rules.Timeout : se usa para limitar la continuación máxima de las pruebas. Primero debe instalarse, ya que comienza la prueba en una nueva rama.

TestLogger es una clase que permite que la prueba registre eventos en formato json para su uso en análisis ELK. Enriquece eventos con datos de prueba de org.junit.runner.Description. También genera automáticamente eventos para ELK en formato json para comenzar y finalizar la prueba con su duración y resultado

StandStateChecker es una clase que verifica la disponibilidad de la interfaz web del soporte de destino ANTES de inicializar el controlador web. Proporciona una comprobación rápida de que el soporte está disponible en principio.

WaitForAngularCreator : una clase que inicializa el controlador del controlador web para controlar la finalización de las operaciones angulares asíncronas. Se utiliza para personalizar pruebas "especiales" con largas llamadas sincrónicas.

org.junit.rules.TemporaryFolder : se usa para configurar una carpeta temporal única para almacenar archivos para cargar y descargar operaciones mediante un navegador web.

DownloaderCreator es una clase que proporciona soporte para operaciones de carga en un directorio temporal de archivos descargados por el navegador y grabados a través de la función de video Selenoid.

EnvironmentSaver : una clase que agrega información general sobre el entorno de prueba al informe de Allure.  

SessionVideoHandler : una clase que carga un archivo de prueba de video, si lo hay, y aplica Allure al informe.

DriverCreator es una clase que inicializa WebDriver (la clase más importante para las pruebas) dependiendo de los parámetros establecidos: local, solenoide o ggr-selenoid. Además, la clase ejecuta el conjunto de Scripts Java necesarios para nuestras pruebas. Todas las reglas que acceden al controlador web deben inicializarse después de esta clase.

BrowserLogCatcher : una clase que lee mensajes severos del registro del navegador, los registra en ELK (TestLogger) y los aplica al informe de Allure.

ScreenShooter : una clase que para pruebas fallidas toma una captura de pantalla de la pantalla del navegador y la aplica al informe como WebDriverRunner.getWebDriver (). GetScreenshotAs (OutputType.BYTES)

AttachmentFileSaver : una clase que le permite adjuntar al informe Allure un conjunto de archivos arbitrarios requeridos por la lógica empresarial de las pruebas. Se utiliza para adjuntar archivos cargados o descargados al sistema.

FailClassifier es una clase especial que, en el caso de un bloqueo de prueba, intenta determinar si este bloqueo fue causado por problemas de infraestructura. Comprueba la presencia en la pantalla (después de un bloqueo) de ventanas modales especiales del tipo "Error de sistema No.XXXXXXXXXX", así como mensajes del sistema de tipo 404 y similares. Le permite dividir las pruebas caídas en fallas comerciales (según el escenario) o problemas del sistema. Funciona a través de la extensión org.junit.rules.TestWatcher. # Método fallido.

PendingRequestsCatcher es otra clase especial que intenta clasificar aún más si el bloqueo fue causado por servicios de descanso incompletos, bloqueados o muy largos entre la interfaz angular y la interfaz web. Además de las pruebas funcionales, permite identificar servicios problemáticos y de reposo bajo congelación bajo cargas pesadas, así como la estabilidad general de la versión. Para hacer esto, la clase registra en ELK todos los eventos con solicitudes de descanso congeladas que recibe al iniciar js especiales en el navegador a través de un controlador web abierto.

Plantilla de implementación de clase de prueba

 package autotest.test.<sub-system>; @Feature("     TMS") @Story("    TMS") @Owner("       ") @TmsLink("    .   ") public class <   >_Test extends BaseTest { /** *           **/    Login orgTest; /**         **/    Login loginStep1;    ...    Login loginStepN;    /** *   -      -   * ...         **/      /** *    *              *    Utils.allure.message("     -", business_object) *     null,             . *             preconditions  actions    *  Utils.allure.message("      ", documentNumber) **/ @Step("  ") private void init(Login login) {    some_business_object = //         login        Utils.allure.message("     -", some_business_object)                           // ...             /**     */        loginStep1 = LoginFactory.get(_Some_Login_);    ...    loginStepN = LoginFactory.get(_Some_Login_); }    /** *       **/    @Test    @Filter("       JUnit")    @DisplayName("    TMS")    public void <   >_<>_<__>_Test() {  //            orgTest = LoginFactory.get(_Some_Login_);                //               init(orgTest);           //    -.                preconditions();               //             actions(orgTest); }    /** *        **/ @Step(" ") protected void preconditions() {    loginStep1.login();    new SomeAction().apply(someTestObject1, ..., someTestObjectN);        Utils.allure.message("   -      -", someTestObjectN)        ...    }    /** *        */ @Step(" ") protected void actions(Login testLogin) {    testLogin.reLogin();               //                new SomeAction().apply(someTestObject1, ..., someTestObjectN); } } 

Plantilla de implementación de clase de script de prueba

 package autotest.business.actions.some_subsystem; public class SomeAction {            //   PageClassA pageA = new PageClassA(); PageClassB pageB = new PageClassB();    @Step("     TMS")    @Description("     TMS")    public void apply(someTestObject1, ..., someTestObjectN) {    //   TMS        step_1(...);        step_2(...);        ...        step_N(...);    }    @Step("  1    TMS")    private void step_1(...) {       pageA.createSomething(someTestObject1);// just as an example create }    @Step("  2    TMS")    private void step_2(...) {   pageA.checkSomething(someTestObject1);// just as an example }                       ... } 

Implementación de la clase de filtrado de prueba FilterTestRunner

Aquí hay una implementación de la extensión BlockJUnit4ClassRunner para filtrar pruebas basadas en conjuntos de etiquetas arbitrarias.

 /** * Custom runner for JUnit4 tests. * Provide capability to do additional filtering executed test methods * accordingly information that could be provided by {@link FrameworkMethod} */ public class FilterTestRunner extends BlockJUnit4ClassRunner { private static final Logger LOGGER = Logger.getLogger(FilterTestRunner.class.getName()); public FilterTestRunner(Class<?> klass) throws InitializationError {    super(klass); } /** * This method should be used if you want to hide filtered tests completely from output **/ @Override protected List<FrameworkMethod> getChildren() {    //  ,        @Filter       TestFilter filter = TestFilterFactory.get();    List<FrameworkMethod> allMethods = super.getChildren();    List<FrameworkMethod> filteredMethod = new ArrayList<>();    for (FrameworkMethod method: allMethods) {        if (filter.test(method)) {            LOGGER.config("method [" + method.getName() +"] passed by filter [" + filter.toString() + "]" );            filteredMethod.add(method);        } else {            LOGGER.config("method [" + method.getName() +"] blocked by filter [" + filter.toString() + "]" );        }    }    return Collections.unmodifiableList(filteredMethod); } /** * This method should be used if you want to skip filtered tests but no hide them @Override protected boolean isIgnored(FrameworkMethod method) {    …    if (filter.test(method)) {        return super.isIgnored(method);    } else {     return true;  }} */ } 

En la siguiente parte, hablaré sobre cómo implementamos el proceso de cargar un archivo desde el contenedor con el navegador al marco de prueba, y resolvimos el problema de encontrar el nombre del archivo descargado por el navegador.

Por cierto, estaremos encantados de reponer nuestro equipo. Las vacantes actuales están aquí .