GitLab

Descrição

Esta página visa apresentar os padrões de qualidade utilizados no projeto Globo Aplausos.

Sumário

• Husky
• Testes Unitários
  • Como escrever testes unitários
• Testes automatizados
  • Como escrever testes automatizados

Husky

O Husky é uma ferramenta utilizada para o gerenciamento de githooks, que são scripts personalizados que podem ser executados em diferentes etapas do ciclo de integração contínua do Git, como por exemplo antes de um commit ou antes de um push.

No projeto Globo Aplausos, utilizamos o Husky para validar o nome de branches, para que contenham o prefixo de feature ou fix, seguidas da estrutura de US-Número da User Story ou NOUS, em caso de branchs que desenvolvam alguma tarefa que não possui história. No backend, também validamos os testes unitários, que precisam passar para que seja possível dar o push na branch.

A validação de commits é realizada em ambos repositórios, na qual são rodados os scripts de lint e prettier, para que a formatação do código seja mantida durante o desenvolvimento.

Testes Unitários

A utilização de testes é algo essencial durante o desenvolvimento de software. No projeto Globo Aplausos, utilizamos testes unitários no Backend da aplicação para garantir a integridade de suas classes e módulos, além de garantir que as funcionalidades da API comportam-se de maneira esperada.

Para escrever os testes unitários em NestJS, utilizamos a ferramenta Jest, que nos possibilita criar os módulos, serviços e controlares da aplicação para que possamos testá-los diretamente, simulando chamadas a API.

Como escrever testes unitários?

Para escrever um teste unitário, primeiro deve-se identificar a classe que está sendo testada. O arquivo de testes deve seguir a nomenclatura da classe original, como por exemplo, para classe auth.service.ts o nome do arquivo de testes será auth.service.spec.ts, para que ele possa ser identificado pelo Jest. O arquivo também deve sempre estar próximo a classe que ele visa testar, mantendo-se sempre no mesmo nível de repositório.

Com o arquivo de teste criado, podemos começar a descrever nossos casos de teste, utilizando a seguinte estrutura:

describe('Nome da classe testada', () => {

- Declarar a classe a ser testada e suas dependências.


  beforeEach(() => {
    - Inicializa as classes.
  });


  describe('Caso de teste', () => {
     
     it('Deve fazer tal coisa', async () => {
          
         Testa alguma coisa...

    });
  });
});

Analisando a estrutura acima, o método beforeEach será rodado antes de cada um dos casos de teste, como por exemplo inicializar as classes e dependências a serem testadas ou providenciar algum Mock.

Para declarar os casos de teste, seguimos a função de describe, para criar os grupos que irão armazenar estes casos de testes, e a função it para declarar um caso de teste.

Debugando um teste

Para debugar um teste, é necessário:

1. Instalar as extensões Jest e Jest Runner, para que seja possível executar rodar um teste individualmente.

2. Ativar o debug auto attach toggle do VSCode para smart ou always.

3. Executar o teste desejado, colocando breakpoints onde for necessário investigar.

Testes automatizados

Cypress é uma ferramenta de teste de software utilizada para realizar testes automatizados de interface de usuário e testes e2e em aplicações web. No projeto Globo Aplausos, utilizamos testes automatizados para validar o fluxo do usuário e as funcionalidades desenvolvidas no Backend e Frontend da aplicação.

Os testes automatizados do projeto Globo Aplausos podem ser encontrados dentro do repositório Globo Aplausos QA

Como escrever testes automatizados

Para escrever um teste automatizado, primeiro deve-se identificar a funcionalidade que está sendo testada. O arquivo de testes deve seguir a nomenclatura da funcionalidade, como por exemplo, para testar o login o nome do arquivo de testes será login.cy.ts, para que ele possa ser identificado pelo Cypress. O arquivo deve estar dentro da pasta e2e.

Com o arquivo criado, podemos começar a descrever nossos casos de teste, utilizando a seguinte estrutura:

1. Criar arquivo de testes dentro da pasta e2e.

2. Criar um describe para agrupar os casos de teste.

3. Criar um caso de teste dentro do describe utilizando terminologia it.

describe('Feature', () => {

 it('caso de teste', () => {
   cy.login() -> faz login no projeto.

   cy.get('algum componente') -> busca algum elemento do HTML da página.

   cy.click() -> clica em algum componente.

   cy.type('texto') -> digita o texto desejado.

   cy.should('alguma condição') -> faz alguma asserção baseada na condição.
 }
});

Mais informações sobre Cypress podem ser encontradas na documentação a seguir: Cypress

Certificado SSL

Para habilitar o uso do protocolo HTTPs em nossa API de backend e obter um certificado SSL, que está hospedada em uma instância EC2 da AWS, empregamos a ferramenta Nginx para configurar um servidor reverse proxy. O servidor proxy reverso redireciona o tráfego da porta 8080 para a porta 443, onde o HTTPs será habilitado.

Antes de obter um certificado SSL, é fundamental possuir um domínio para a aplicação. Existem várias maneiras de adquirir um domínio, inclusive opções gratuitas, e em nosso projeto, optamos por utilizar o DuckDNS.

Para garantir que, mesmo quando nossa instância é reiniciada, o domínio continue apontando para o endereço IPv4 atualizado da instância, implementamos o script indicado. Esse script é projetado para ser executado automaticamente toda vez que a instância é reiniciada. Isso assegura que a associação entre o domínio e o endereço IP da instância permaneça atualizada e funcional, mantendo a disponibilidade da aplicação ininterrupta.

Uma vez que o servidor da API está configurado para escutar na porta 443, podemos empregar a ferramenta Certbot, fornecida pelo Let's Encrypt, para obter um certificado SSL válido. Esse certificado SSL garantirá a segurança das comunicações entre os clientes e o servidor, protegendo os dados transmitidos pela API.