Objet de domaine avec Lombok: Battle Classic

Objet de domaine ( russe. "Objet de domaine" ) - l'une des approches les plus populaires pour utiliser les données de test directement dans la logique du script. À l'heure actuelle, c'est l'une des approches les plus populaires et les plus répandues en raison de sa simplicité, de sa compréhensibilité et de sa logique.

Il est applicable dans tous les types d'automatisation des tests fonctionnels (End-to-End, API, Intégration), quelle que soit la plateforme testée, qu'elle soit Web, Mobile ou Desktop.

IMPORTANT : ne confondez pas objet de domaine et objet de transfert de données (DTO) . Ce sont des approches complètement différentes qui sont appliquées dans différents domaines.

Quelle est son essence?

D'un autre nom de l'approche - «Business Object» - il devient clair qu'il s'agit d'une sorte d'abstraction, qui est un modèle et une description d'un objet qui est important pour la compréhension et le fonctionnement de la logique métier de l'application . Il n'est pas capable d'exécuter d'autres fonctions que le «transfert» des champs et de leurs valeurs vers une unité commerciale spécifique.

---

À quoi ça ressemble

Par exemple, prenez n'importe quelle application qui prévoit la création d'un compte d'utilisateur. C'est l'utilisateur qui devient notre objet de domaine. Dans presque tous les cas, l'utilisateur doit avoir un nom d'utilisateur et un mot de passe:

//    User public class User { // ,  User    Login private String login; // ,  User    Password private String password; } 

Les personnes particulièrement prudentes remarqueront que tous les champs internes sont privés. La définition et la lecture de valeurs directement à partir des champs d'un objet est considérée comme une mauvaise pratique. Au lieu de cela, il est habituel d'utiliser des getters et setters bien connus:

 public class User { private String login; private String password; //      login public void setLogin(String login) { this.login = login; } //     login public String getLogin() { return this.login; } //    public void setPassword(String password) { this.password = password; } public String getPassword() { return this.password; } } 

Maintenant, nous avons accès aux champs, et nous pouvons définir et lire leurs valeurs. Mais dans cet exemple, nous n'utilisons que deux champs. Et que se passe-t-il s'il y a quinze de ces domaines? Certes, la classe User se développe à des tailles sans précédent, grâce à la pâte de copie sans fin des getters et setters. Comment allons-nous y faire face?

---

Magic lombok

C'est là que Project Lombok vient à la rescousse - une bibliothèque populaire qui nous permet de réduire plusieurs fois le code, d'éviter les souffrances de copier / coller et de réduire considérablement le temps nécessaire pour écrire des classes d'objets de données. Quelques liens utiles:

• Site officiel du projet Lobmok
• Guide d'installation du plug-in IntelliJ IDEA
• Lombok à Maven Central

Que fait-il? Crée automatiquement des getters et setters pour tous les champs de la classe, en lui affectant l'annotation correspondante:

 import lombok.Getter; import lombok.Setter; //       User @Getter //       User @Setter public class User { private String login; private String password; } 

Simple, rapide, pratique. Ainsi, notre code devient beaucoup plus lisible, les classes sont plus concises et le développement est plus rapide.

---

Appliquer en test

Un bon test est un test dans lequel les données de test, la logique de test et sa mise en œuvre sont clairement séparées.

Essayons de connecter notre utilisateur. Nous créons une classe avec des données de test et les «remplissons» avec un nouvel utilisateur:

 //  Test Data  public class TestDataUser { //  private-    private final static String DEFAULT_LOGIN = "vasiliy_pupkin"; private final static String DEFAULT_PASSWORD = "q1w2e3"; //        public static User getDefaultUser() { //  ""  User user = new User(); //      Login user.setLogin(DEFAULT_LOGIN); //      Password user.setPassword(DEFAULT_PASSWORD); //    User,     return user; } } 

Nous décrivons le modèle de la page de connexion:

 public class LoginPage { //  public- ,    User public void loginUser(User user) { //          enterLogin() enterLogin(user.getLogin()); //    enterPassword(user.getPassword()); } private void enterLogin(String login) { this.loginInput.sendKeys(login); } private void enterPassword(String password) { this.passwordInput.sendKeys(password); } } 

Il ne reste plus qu'à implémenter la classe de test:

 public class LoginTest { @Test public void loginAsDefaultUser() { //    credentials   User user = TestDataUser.getDefaultUser(); //  Login- LoginPage loginPage = new LoginPage(); // ,     loginPage.loginUser(user); } } 

C'est fait! Tu es génial!

---

Pour résumer

Au final, nous obtenons une architecture de projet soignée , avec une séparation claire de la logique, des données et de l'implémentation. Lombok vous aide à vous débarrasser de la duplication de code, Domain Object s'intègre parfaitement dans la philosophie Page Page Object et le support de code devient un vrai plaisir.

Devrait-il y avoir des inconvénients?

1. Immunité. Ou plutôt, son absence. En cela, cette approche utilisant Lombok perd face au principal concurrent - Builder ( article sur Habré ). Mais, à mon avis, le code ci-dessus est plus «propre», compréhensible et agréable sur le plan esthétique, par rapport à la chaîne sans fin du générateur et au tas de méthodes de la classe Object.
2. Augmentez la complexité là où elle n'est pas nécessaire. Pas tant moins qu'un petit rappel. Toute approche ou modèle est problématique et devrait résoudre un certain problème. Vous ne devez pas essayer d'utiliser l'objet de données dans un test unitaire qui vérifie uniquement que 2 + 2 = 4.

Merci beaucoup pour votre attention. Je serai ravi des critiques et critiques.

PS Dites dans les commentaires quelles approches vous utilisez dans votre travail. Ce sera très intéressant à lire.