Objeto de domínio com Lombok: Battle Classic

Objeto de domínio ( russo. "Objeto de domínio" ) - uma das abordagens mais populares para o uso de dados de teste diretamente na lógica dos scripts. No momento, é uma das abordagens mais populares e difundidas devido à sua simplicidade, compreensibilidade e lógica.

É aplicável em todos os tipos de automação de testes funcionais (ponta a ponta, API, integração), independentemente da plataforma que está sendo testada, seja Web, móvel ou desktop.

IMPORTANTE : Não confunda o objeto de domínio com o objeto de transferência de dados (DTO) . Essas são abordagens completamente diferentes, aplicadas em diferentes campos.

Qual é a sua essência?

De outro nome da abordagem - “Objeto de Negócios” - fica claro que esse é um tipo de abstração, que é um modelo e uma descrição do objeto, importante para entender e funcionar a lógica de negócios do aplicativo . Ele não é capaz de executar outras funções além de "transferir" campos e seus valores para uma unidade de negócios específica.

---

Como é isso?

Como exemplo, considere qualquer aplicativo que forneça a criação de uma conta de usuário. É o usuário que se torna nosso objeto de domínio. Em quase todos os casos, o usuário deve ter um nome de usuário e senha:

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

Especialmente cuidadosos perceberão que todos os campos internos são particulares. Definir e ler valores diretamente dos campos de um objeto é considerado uma má prática. Em vez disso, é habitual usar getters e setters conhecidos:

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

Agora, temos acesso aos campos e podemos definir e ler seus valores. Mas neste exemplo, usamos apenas dois campos. E o que acontece se houver quinze desses campos? É verdade que a classe User se expande para tamanhos sem precedentes, graças à infinita pasta de cópias de getters e setters. Como vamos lidar com isso?

---

Lombok mágico

Aqui o Project Lombok vem em socorro - uma biblioteca popular que nos permite reduzir o código várias vezes, evitar o sofrimento de copiar / colar e reduzir significativamente a quantidade de tempo que leva para escrever classes de objetos de dados. Alguns links úteis:

• Site oficial Projeto Lobmok
• Guia de instalação do plug-in IntelliJ IDEA
• Lombok na Maven Central

O que ele esta fazendo? Cria automaticamente getters e setters para todos os campos da classe, atribuindo a anotação correspondente:

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

Simples, rápido, conveniente. Assim, nosso código se torna muito mais legível, as classes são mais concisas e o desenvolvimento é mais rápido.

---

Aplicar no teste

Um bom teste é um teste no qual dados de teste, lógica de teste e sua implementação são claramente separados.

Vamos tentar entrar em nosso usuário. Criamos uma classe com dados de teste e os "preenchemos" com um novo usuário:

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

Descrevemos o modelo da página de login:

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

Resta apenas implementar a classe de teste:

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

Feito! Você é demais!

---

Resumir

No final, obtemos uma arquitetura de projeto elegante , com uma clara separação de lógica, dados e implementação. O Lombok ajuda você a se livrar da duplicação de código, o Objeto de Domínio se encaixa perfeitamente com a filosofia do Objeto de Página, e o suporte ao código se torna um verdadeiro prazer.

Deveria haver menos?

1. Imunidade. Ou melhor, sua ausência. Nesse sentido, essa abordagem usando Lombok perde para o principal concorrente - Builder ( artigo sobre Habré ). Mas, na minha opinião, o código acima é mais "limpo", compreensível e esteticamente agradável, comparado à cadeia interminável no construtor e à pilha de métodos na classe Object.
2. Aumente a complexidade onde não for necessário. Não tanto menos como um pequeno lembrete. Qualquer abordagem ou padrão é problemático e deve resolver um determinado problema. Você não deve tentar usar o objeto de dados em um teste de unidade que verifique apenas se 2 + 2 = 4.

Muito obrigado pela atenção. Ficarei feliz em comentários e críticas.

PS Diga nos comentários quais abordagens você usa em seu trabalho. Será muito interessante ler.