Esta apresentação tem como foco demonstrar um pouco do motivo para o qual devemos testar nosso software e apresenta algumas estratégias para facilitar isso se tornar parte do dia a dia

1. about me
Victor Yuri Alves Tripeno
Creditas / Software Engineer
29 years old
● Formado em Análise e Desenvolvimento de Sistemas
● Bebedor de cerveja

2. TESTS

3. TABLE OF
CONTENTS
why tests?01
clean architecture02
testing strategy03
mutation testing04

4. why tests?

5. ● redução de custos, ganho na qualidade gerando maior retorno em
relação ao investimento realizado.;
reduz a quantidade de esforço que seria realizado em testes manuais;
código limpo e bem escrito, resultado da simplicidade na hora de criá-lo
e o tempo para refatorar;
facilidade e segurança para corrigir bugs, já que você trabalha com o
código fração por fração;
modularidade e flexibilidade no seu código, proporcionados por essa
quebra em pequenos objetivos;
economia de tempo sem perder qualidade de desenvolvimento, com
menos bugs para corrigir e menos retrabalho

6. why clean
architecture?

7. The center of your application is not the database. Nor is it
one or more of the frameworks you may be using. The center
of your application is the use cases of your application -
Unclebob

8. common problems in architecture:
● é difícil encontrar as coisas o que torna cada mudança longa e
dolorosa;
lógicas de negócio está espalhada por toda parte;
testar é extremamente custoso, pois os testes são lentos, pesados ​​e
quebradiços;
deploy grandes e arriscados

9. clean architecture gives us all these benefits:
● confiança! usar estratégia de testes eficaz em conjunto com a pirâmide
de teste;
independente de framework e módulos isolados;
regras de negócio (use cases) totalmente isolados;
a arquitetura “grita” o seu propósito desde a estrutura de pacotes até as
classes;
sempre pronto para implantar;
múltiplos team members atuando no mesmo código;
sistemas monolíticos com use cases bem definidos, serão ótimos
microserviços;

11. of course, it comes at a cost...
● duplicação de código;
suas regras de negócio devem de fato justificar o uso da arquitetura;

12. testing strategy

13. dores comuns durante a fase de teste
● falta de clareza dos requisitos;
requisições frequentes de scope-creep (oportunistas);
falta de visibilidade após a conclusão dos testes (camadas cobertas,
defeitos ou cenários incompletos);
Testes escritos depois das funcionalidades estarem desenvolvidas e
prontas;
comunicação entre desenvolvedores, QAs e pessoas de negócio não é
clara;

18. mutation testing

19. Mutation testing (or mutation analysis or program mutation) is
used to design new software tests and evaluate the quality of
existing software tests.

20. if (“joaozinho”.equals(nome) {
System.out.println(“joaozinho”);
}
if (nome.equals(“joaozinho”) {
System.out.println(“joaozinho”);
}

21. THANKS!