☝🏼 🍳 👩🏼‍🤝‍👨🏿 Modèle de cadre de test simple et pratique sur séléniure pour les autotests de l'interface utilisateur 👂 🍆 🆖

Bonjour.

Dans cet article, je voudrais partager mon expérience dans l'automatisation des tests fonctionnels. Il s'agira d'écrire un cadre de test pratique et fiable.

Ce que nous utiliserons: Java, Selenide, Alure, TestNG, Maven.

introduction

Projet GitHub - SelenideBoilerplate .

Souvent dans les articles sur l'automatisation des tests, les exemples sont loin de la réalité, par exemple:

driver.get (“URL”)
driver.find_element_by_id(“ID”).send_keys(“username”)
driver.find_element_by_id (“ID”).send_keys(“password”)
driver.find_element_by_id(“submit”).click()

Il existe de nombreux exemples similaires d'attentes, d'objets de page, etc. En conséquence, il peut être difficile pour un testeur débutant de tout organiser correctement et commodément. Le projet est surchargé de béquilles, c'est pourquoi il devient de plus en plus difficile d'écrire de nouveaux tests et de maintenir les anciens.

Il y a aussi des outils trop verbeux et trop compliqués à mon avis.

Je vais vous montrer un framework de test simple, pratique et facilement extensible, qui est beaucoup plus facile à travailler que le sélénium ordinaire et que j'ai utilisé avec succès sur plusieurs projets. Ce projet est la base, sur des projets réels tout est un peu plus compliqué (parallélisation, remoteDriver, nombreux tests, etc.).

Outils

Selenide est une bibliothèque pour écrire des tests d'interface utilisateur open source concis et stables. Selenide résout la plupart des problèmes de délais d'attente, de clics sur des éléments qui n'ont pas réussi à se charger, etc. Vous pouvez également oublier l' exception StaleElementReferenceException . Un outil très pratique et facile à apprendre, après avoir travaillé avec lequel vous ne voulez plus revenir au sélénium.
WebDriverManager - Inclus dans Selenide. Une bibliothèque qui fait tout le travail de téléchargement de pilotes pour un navigateur et de définition de chemins de pilotes -
```
 System.setProperty("webdriver.browser.driver", "/path_to_driver/driver"); 
```
Attrait pour les rapports.
TestNG est un framework de test.
Maven est un outil pour automatiser l'assemblage de projets.

Structure du projet

Commençons par les modules d' application et de pages .

PageBuilder, classe

En règle générale, les exemples donnent des pages assez simples où tout tient dans une seule classe. Mais sur de vrais projets, il peut y avoir des pages assez grandes, décrivant toutes les fonctionnalités dont dans une classe n'est pas la meilleure idée. Par exemple, cela pourrait être une page de recharge avec de nombreuses formes de systèmes de paiement différents.

Dans ce cas, il est préférable de diviser la page en plusieurs classes et même éléments (par exemple, un produit dans le panier) et de tout regrouper dans la classe principale de la page.

Par conséquent, il est préférable de créer toutes les pages au même endroit, à savoir dans la classe PageBuilder .

package app;

import app.pages.LoginPage;

public class PageBuilder {

    public static LoginPage buildLoginPage() {
        return new LoginPage("/login");
    }

    public static BalancePage buildBalancePage() {
        DepositForm depositForm = new DepositForm();
        WithdrawalForm withdrawalForm = new WithdrawalForm();
        return new BalancePage("/balance", depositForm, withdrawalForm);
    }
}

Classe AppConfig

La classe AppConfig stocke les paramètres de l'application Web testée. Par exemple - l'adresse du site, les utilisateurs de test, etc. Dans ce projet, il s'agit simplement de l'adresse du site.

package app;

public class AppConfig {

    public static final String baseUrl = "https://google.com";

}

Classe d'application

Il s'agit de la classe principale de ce module. Dans le constructeur de la classe App , toutes les pages sont créées.

package app;

import app.pages.LoginPage;

public class App {

    public LoginPage loginPage;

    public App() {
        loginPage = PageBuilder.buildLoginPage();
    }
}

Grâce à cette approche, il n'est pas nécessaire de créer constamment des objets de page dans les tests, seul l'objet App est créé à partir duquel les pages nécessaires sont obtenues.

Dans la classe App , il peut également y avoir des méthodes telles que: enregistrement, enregistrement et création de commande, etc.

C'est-à-dire de grandes opérations dans lesquelles plusieurs objets de page sont impliqués et qui sont souvent nécessaires dans les tests.

Passons aux objets de page

Grâce à Selenide, travailler avec des objets de page est facile. Toutes les pages héritent de la classe de base BasePage . L'URL de page relative est transmise au constructeur d'objet de page.

Tous les éléments de page ont un modificateur d' accès public , vous pouvez donc écrire des tests dans des styles impératifs et déclaratifs. De plus, à partir des éléments, vous pouvez obtenir les données nécessaires, telles que du texte ou un attribut.

Le localisateur est stocké en un seul endroit. Toute logique de page doit être décrite dans les méthodes de page.

Avec cette approche, si quelque chose se casse ou change, dans la plupart des cas, il n'est pas nécessaire de réécrire les tests, la méthode est juste finalisée ou le localisateur change pour le test réel.


package app.pages;

import com.codeborne.selenide.SelenideElement;
import helpers.Driver;
import static com.codeborne.selenide.Selenide.*;

public class LoginPage extends BasePage {

    public SelenideElement loginField = $("#login__username");
    public SelenideElement passwordField = $("#login__password");
    public SelenideElement signInButton = $("#login_enter");
    public SelenideElement termsOfUseLabel = $("label[for=\"login_agree\"]");

    public LoginPage(String pageUrl) {
        super(pageUrl);
    }
    
    public void login(String email, String password) {
        loginField.setValue(email);
        passwordField.setValue(password);
        termsOfUseLabel.click();
        signInButton.click();
        Driver.waitForUrlContains("account/accounts");
    }
}

Du repos

Le module helpers contient 2 classes importantes:

TestConfig - A partir de cette classe, vous pouvez obtenir les paramètres avec lesquels les tests sont exécutés. Les paramètres par défaut sont également affichés ici.

Les tests sont exécutés par la commande. mvn test -Dbrowser=chrome -Dheadless=1

Les valeurs des variables sont extraites de la ligne de commande et, grâce à la classe TestConfig, sont disponibles dans les tests et dans l'application.

Par exemple, vous pouvez modifier l'URL de l'application en fonction de l'environnement (développeur, stade, production).


package helpers;

public class TestConfig {

    public static String browser = "chrome";
    public static String headless = "1";

    public static void initConfig() {
        browser = System.getProperty("browser") == null ? "chrome" : System.getProperty("browser");
        headless = System.getProperty("headless") == null ? "1" : System.getProperty("headless");
    }

    public static boolean isHeadless() {
        return headless.contains("1");
    }
}

La classe Driver est mon enveloppe sur les pilotes sélénium et séléniure avec quelques méthodes utiles.

Les méthodes les plus importantes:

Driver.initDriver () - ici le pilote / navigateur est initialisé.

   public static void initDriver() {

        // Get settings from command line

        TestConfig.initConfig();

        // Set settings for selenide browser

        Configuration.pageLoadStrategy = "eager";
        Configuration.browserSize = "1920x1080";
        Configuration.holdBrowserOpen = false;
        Configuration.screenshots = false;

        if(TestConfig.isHeadless()) {
            Configuration.headless = true;
        } else {
            Configuration.headless = false;
        }

        switch (TestConfig.browser) {
            case "chrome":
                Configuration.browser = Browsers.CHROME;
                break;
            case "firefox":
                Configuration.browser = Browsers.FIREFOX;
                break;
            default:
                Configuration.browser = Browsers.CHROME;
                break;
        }
    }

Driver.clearCookies()
Driver.close()

Les tests

Toutes les classes de test sont héritées de la classe A_BaseTest , dans laquelle l'objet d'application App est créé , logger , softAssert , le navigateur s'ouvre et se ferme, les cookies sont effacés après chaque test.

Il existe également un A_BaseTestListener où les erreurs peuvent être enregistrées.

Les tests ressemblent à ceci. Facile à lire, facile à entretenir.

import org.testng.annotations.Test;

public class ExampleTest extends A_BaseTest
{
    @Test
    public void loginViaEmail() {
        app.loginPage.open();
        app.loginPage.login("email@email.com", "passwords");
        
        logger.info("Sample info message");
               
        softAssert.assertEquals(2,2);
        softAssert.assertAll();
    }
}

Les classes de test sont spécifiées dans testng.xml .

Le dossier de sortie de test contient des journaux et des captures d'écran - Driver.takeScreenshot () .

Pour les rapports, Allure est utilisé . Une fois les tests terminés, vous pouvez exécuter la commande allure serve target/allure-resultset consulter le rapport.

Projet GitHub - SelenideBoilerplate

Modèle de cadre de test simple et pratique sur séléniure pour les autotests de l'interface utilisateur