| ... | @@ -10,6 +10,8 @@ Esta página visa apresentar os padrões de qualidade utilizados no projeto Glob |
... | @@ -10,6 +10,8 @@ Esta página visa apresentar os padrões de qualidade utilizados no projeto Glob |
|
|
- [Testes Unitários](#testes-unitários)
|
|
- [Testes Unitários](#testes-unitários)
|
|
|
- [Como escrever testes unitários](#como-escrever-testes-unitários)
|
|
- [Como escrever testes unitários](#como-escrever-testes-unitários)
|
|
|
- [Testes automatizados](#testes-automatizados)
|
|
- [Testes automatizados](#testes-automatizados)
|
|
|
|
- [Como escrever testes automatizados](#como-escrever-testes-automatizados)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Husky
|
|
## Husky
|
| ... | @@ -33,7 +35,7 @@ Para escrever os testes unitários em NestJS, utilizamos a ferramenta [Jest](htt |
... | @@ -33,7 +35,7 @@ Para escrever os testes unitários em NestJS, utilizamos a ferramenta [Jest](htt |
|
|
|
|
|
|
|
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.
|
|
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 testes criados, podemos começar a descrever nossos casos de teste, utilizando a seguinte estrutura:
|
|
Com o arquivo de teste criado, podemos começar a descrever nossos casos de teste, utilizando a seguinte estrutura:
|
|
|
|
|
|
|
|
|
|
|
|
|
``````
|
|
``````
|
| ... | @@ -80,3 +82,9 @@ Para debugar um teste, é necessário: |
... | @@ -80,3 +82,9 @@ Para debugar um teste, é necessário: |
|
|
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.
|
|
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](https://tools.ages.pucrs.br/globo-aplausos/globo-aplausos-qa)
|
|
Os testes automatizados do projeto Globo Aplausos podem ser encontrados dentro do repositório [Globo Aplausos QA](https://tools.ages.pucrs.br/globo-aplausos/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: |
|
|
|
\ No newline at end of file |
