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
- Separe responsabilidades em módulos
Agora se você já leu os primeiros posts da série, vamos falar sobre a sexta guideline do Better Code Hub: Acople a arquitetura de componentes fracamente.
Segundo o BCH:
- Ter um acoplamento fraco entre os componentes de nível superior facilita manter os componentes isolados.
- Faça isso minimizando a quantidade de interfaces; ou seja, codifique em módulos que são chamados e chamam módulos de outros componentes.
- Você pode esconder detalhes de implementação de componentes de várias maneiras, tais como usar o padrão de projeto “abstract factory”.
Ter um acoplamento fraco entre os componentes de nível superior facilita manter os componentes isolados
No conteúdo anterior da série foi explicado que manter a base de código fracamente acoplada facilita minimizar as consequências das mudanças.
Porém, esta guideline vai um pouco além e fala sobre componentes de nível superior.
Vamos usar como exemplo o projeto de testes end-to-end do curso de arquitetura de testes com Protractor da Escola Talking About Testing. Neste projeto, os componentes de nível superior são os testes propriamente ditos, ou seja, os arquivos dentro do diretório specs/, e os outros componentes, de nivel inferior, são por exemplo os Page Objects e os components.
A grande “sacada” aqui é que tanto os Page Objects como os components não sabem nada sobre os testes, só os testes que sabem sobre eles, portanto, mudanças nos testes não afetam estes outros componentes.
Também podemos pensar que Page Objects estão em um nível superior com relação aos components, e portanto, mudanças nos Page Objects também não afetam os components.
Na arquitetura de testes do curso de Protractor utilizo o termos components, em inglês, como uma abstração de componentes de uma página web, porém, neste post quando se trata de componentes, em português, estamos falando de qualquer parte isolada de um projeto de software. No caso de testes end-to-end, estes podem ser os Page Objects, testes, arquivos de configuração, etc.
Podemos até mesmo pensar em arquivos de configuração como componentes em um nível superior quando comparados com testes, e portanto, mudanças em testes não interferem em configurações.
Minimize a quantidade de interfaces; ou seja, codifique em módulos que são chamados e chamam módulos de outros componentes
Ainda utilizando o mesmo exemplo, vamos pensar nas interfaces de nossos componentes. As interfaces de ambos os Page Objects como dos components, são simplesmente instâncias de classes.
Se você precisa utilizar um determinado Page Object em uma suite de testes, basta importá-lo e criar uma nova instância da page no arquivo de teste (*.spec.js), como pode ser visto neste teste, nas linhas 3, 4, 9 e 10.
O mesmo vale para os components, onde quando necessários em um determinado Page Object, são simplesmente importados e instanciados como objetos de classe, expondo assim seus elementos (em forma de atributos de classe) e métodos, como pode ser visto neste Page Object, nas linhas 1, 2, 3, 9, 10 e 11.
Ou seja, testes chamam Page Objects, que chamam components.
Esconda detalhes de implementação utilizando padrões de projeto
Um dos padrões de projeto (design patterns) sugerido pelo BCH é o padrão chamado abstract factory.
Absract factory, ou fábrica abstrata, é um padrão de projetos que lhe permite criar objetos diversos, com diferentes variações, porém todos compartilham de uma mesma interface.
Ainda utilizando como exemplo o projeto do curso de arquitetura de testes com Protractor da Escola Talking About Testing, podemos ver o arquivo que cria as configurações padrão dos testes como uma abstract factory, a qual pode criar diversas configurações específicas por navegador, porém todas compartilharão as mesmas configurações padrão, e implementarão suas especificidades, tais como em qual navegador os testes vão rodar, e quais opções devem ser passadas ao driver do navegador para executar os testes em modo headless, por exemplo.
O próximo post da série será: Mantenha a arquitetura de componentes equilibrada.
Até a próxima e bons testes! 👋
Recado para o meu eu do futuro: atualizar conteúdo com alguns exemplos em código, podendo até mesmo ser cópias dos exemplos citados no post, e atualizar com explicação própria sobre a parte de padrões de projeto, aplicados à testes.
TALKING ABOUT TESTING 
Hey, there’s a typo in abstract factory, both times you mention it! And thanks for the post!
Fixed. Obrigado Deiva!