Objeto de dominio con Lombok: Battle Classic

Objeto de dominio ( ruso. "Objeto de dominio" ): uno de los enfoques más populares para usar datos de prueba directamente en la lógica de los scripts. Por el momento, es uno de los enfoques más populares y extendidos debido a su simplicidad, comprensión y lógica.

Es aplicable en todos los tipos de automatización de pruebas funcionales (de extremo a extremo, API, integración), independientemente de la plataforma que se esté probando, ya sea web, móvil o de escritorio.

IMPORTANTE : No confunda el Objeto de dominio con el Objeto de transferencia de datos (DTO) . Estos son enfoques completamente diferentes que se aplican en diferentes campos.

¿Cuál es su esencia?

A partir de otro nombre del enfoque, “Objeto comercial”, queda claro que se trata de una especie de abstracción, que es un modelo y una descripción del objeto, que es importante para comprender y funcionar la lógica comercial de la aplicación . No es capaz de realizar ninguna función que no sea "transferir" campos y sus valores a una unidad de negocio específica.

---

Como se ve

Como ejemplo, tome cualquier aplicación que permita la creación de una cuenta de usuario. Es el usuario el que se convierte en nuestro objeto de dominio. En casi todos los casos, el usuario debe tener un nombre de usuario y contraseña:

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

Los especialmente cuidadosos notarán que todos los campos internos son privados. Establecer y leer valores directamente desde los campos de un objeto se considera una mala práctica. En cambio, se acostumbra usar getters y setters conocidos:

 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; } } 

Ahora, tenemos acceso a los campos, y podemos establecer y leer sus valores. Pero en este ejemplo, usamos solo dos campos. ¿Y qué pasa si hay quince de estos campos? Es cierto que la clase de usuario se expande a tamaños sin precedentes, gracias a la copia sin fin pegar de getters y setters. ¿Cómo lidiaremos con esto?

---

Lombok mágico

Aquí es donde el Proyecto Lombok viene al rescate: una biblioteca popular que nos permite reducir el código varias veces, evitar el sufrimiento de copiar / pegar, y reducir significativamente la cantidad de tiempo que lleva escribir clases de objetos de datos. Algunos enlaces útiles:

• Sitio oficial del Proyecto Lobmok
• Guía de instalación para el complemento IntelliJ IDEA
• Lombok en Maven Central

Que esta haciendo el Crea automáticamente getters y setters para todos los campos de la clase, asignándole la anotación correspondiente:

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

Simple, rápido, conveniente. Por lo tanto, nuestro código se vuelve mucho más legible, las clases son más concisas y el desarrollo es más rápido.

---

Aplicar en prueba

Una buena prueba es una prueba en la que los datos de prueba, la lógica de prueba y su implementación están claramente separados.

Intentemos iniciar sesión en nuestro usuario. Creamos una clase con datos de prueba y los "llenamos" con un nuevo Usuario:

 //  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; } } 

Describimos el modelo de la página de inicio de sesión:

 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); } } 

Solo queda implementar la clase de prueba:

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

Hecho Eres genial

---

Para resumir

En la final, obtenemos una arquitectura de proyecto ordenada , con una clara separación de lógica, datos e implementación. Lombok lo ayuda a deshacerse de la duplicación de código, Domain Object encaja perfectamente con la filosofía de Page Object y el soporte de código se convierte en un verdadero placer.

¿Debería haber desventajas?

1. Inmunidad O más bien, su ausencia. En esto, este enfoque con Lombok pierde ante el principal competidor: Builder ( artículo sobre Habré ). Pero, en mi opinión, el código anterior es más "limpio", comprensible y estéticamente agradable, en comparación con la cadena sin fin en el generador y el montón de métodos en la clase Object.
2. Aumentar la complejidad donde no se necesita. No tanto menos como un pequeño recordatorio. Cualquier enfoque o patrón es problemático y debería resolver un problema determinado. No debe intentar usar el Objeto de datos en una prueba unitaria que solo verifica que 2 + 2 = 4.

Muchas gracias por su atención Estaré encantado de comentarios y críticas.

PD: Diga en los comentarios qué enfoques utiliza en su trabajo. Será muy interesante de leer.