Separe responsabilidades em módulos

Mais um post da série de qualidade de código em teste de software

Se você está chegando neste post agora e ainda não leu os conteúdos anteriores, recomendo começar por eles. Seguem os links:

• Escreva pequenas unidades de código
• Escreva simples unidades de código
• Escreva código uma só vez
• Mantenha as interfaces da unidade pequenas

Agora se você já leu os primeiros posts da série, vamos falar sobre a quinta guideline do Better Code Hub: Separe responsabilidades em módulos.

Segundo o BCH:

• Mantenha a base de código fracamente acoplada, pois isso facilita minimizar as consequências das mudanças.
• Identifique e extraia as responsabilidades de módulos grandes para separá-los, e esconda detalhes de implementação atrás de interfaces.
• Esforce-se para que um módulo receba chamadas de não mais do que 10 outras partes do sistema.

Mantenha a base de código fracamente acoplada, pois isso facilita minimizar as consequências das mudanças

Um exemplo que demonstra bem este item da guideline é o projeto de testes end-to-end do curso de arquitetura de testes com Protractor da Escola Talking About Testing.

Neste projeto as responsabilidades estão bem definidas e separadas, sendo 1) arquivos de configuração (base e específicos); 2) constantes (constants); 3) testes (specs); 4) page objects; e 5) componentes (components).

A arquitetura proposta neste projeto possibilita que, se uma mudança é necessária em um determinado módulo, como a definição de um elemento em um componente, a mudança de uma URL relativa em um page object, uma configuração para execução dos testes, ou um teste propriamente dito, tal mudanças não irá afetar outras partes do sistema, ou seja, minimizando as consequências das mudanças.

Identifique e extraia as responsabilidades de módulos grandes para separá-los, e esconda detalhes de implementação atrás de interfaces

Antigamente, quando trabalhando com testes automatizados de interface gráfica de usuário (GUI), eu ficava satisfeito com a única separação de tais testes em arquivos de testes (spec files) e page objects, porém, com o tempo e com projetos expandindo, percebi que tal abordagem não era sustentável, visto que na ocorrência de páginas web com muitos elementos, os page objects ficavam muito grandes e difíceis de dar manutenção.

Foi aí que, inspirado por uma palestra na Selenium Conf Berlim em 2017,criei e comecei a utilizar e evoluir uma arquitetura de testes utilizando não só page objects, mas também componentes, onde os componentes podem ser reutilizados em páginas que possuem elementos em comum, ou mesmo para melhor separar page objects compostos por diferentes “componentes”. Tal abordagem viabiliza módulos simples e menores, facilitando a manutenção.

No caso desta proposta de arquitetura de testes end-to-end, a interface para a criação de um determinado page object ou de um componente são basicamente a criação de objetos baseados em instâncias de classes. Simples!

Esforce-se para que um módulo receba chamadas de não mais do que 10 outras partes do sistema

O ponto aqui é que se um determinado módulo está recebendo chamadas de muitas outras partes do sistema, há chances deste estar acumulando muitas responsabilidades, e portanto, pode ser necessário separar tais responsabilidades em diferentes módulos, pois se um modulo é usado por demasiadas partes, isso pode danificar a capacidade de mantê-lo desacoplado.

---

E por falar em manter módulos desacoplados, o próximo post da série será: Acople a arquitetura de componentes fracamente.

Até a próxima e bons testes! 👋