Trilha de Testes de Software 101

Chegou a hora de embarcar na trilha de Testes Automatizados e Qualidade de Código!

Essa trilha foi realizada na Creditas para o grupo de mulheres em produto e tecnologia.

Abordaremos conceitos como:

O que é um teste? Por que fazer?
Por que automatizar os testes?
Quais são os tipos de testes que posso fazer?
Como funcionam as bibliotecas?
Técnicas de teste com doubles
Testes de aceitação e e2e
O que é qualidade de software?

Transcript

1. Trilha de Testes
2. Testes automatizados
3. Teste de software
4. Teste de software Teste de Software é um processo que faz parte do desenvolvimento de software e tem como principais objetivos garantir a qualidade da solução desenvolvida e reduzir riscos que podem impactar as usuárias finais da aplicação. “Melhor um bug na mão da desenvolvedora que na mão da usuária”
5. Testar ao longo do desenvolvimento ao invés de testar apenas no final Prevenir bugs ao invés de encontrar bugs Testar o entendimento ao invés de checar funcionalidades Construir o melhor sistema ao invés de quebrar o sistema O manifesto dos testes ágeis O time é responsável pela qualidade ao invés de as testers são responsáveis pela qualidade
6. Testes automatizados
7. Testes automatizados Automação de testes é o uso de ferramentas para controlar a execução dos testes. Os objetivos da automação de testes é tornar a prevenção a erros mais rápida e assertiva e também economia de tempo na execução de tarefas repetitivas. Os testes automatizados também servem como forma de documentar a aplicação e assim facilitar o entendimento do código e entrada de novas pessoas. “Descobrir o inesperado é mais importante do que confirmar o conhecido.“ - George E. P. Box
8. Código Interface O que testar?
9. Código Interface O que testar?
10. Como automatizar?
11. Ferramentas Existem diversas ferramentas no mercado que facilitam a automação dos testes de software
12. SHOW ME THE CODE https://github.com/inajaraleppa/exemplos-teste
13. Testes unitários e integração
14. Pirâmide de testes
15. Pirâmide
16. Teste de unidade É o tipo de teste responsáveis por validar comportamentos individuais da menor partes testável de um software (ex: função, lógica de negócio). O objetivo do teste de unidade é cobrir os diferentes cenários de retorno para um determinado trecho de código, incluindo falhas, casos extremos, etc.
17. Testes de unidade Testes de unidade devem ser orientados à comportamento. Isso garante que ao haver refatoração os testes não quebrem. Uma característica desse tipo de teste é ser isolado de qualquer dependência externa como banco de dados ou serviços externos e algumas vezes isolados de outras lógicas internas da aplicação, utilizando dados fakes quando necessário.
18. Integração O teste de integração é o processo de verificar se os componentes de um software, juntos, possuem o comportamento esperado. Os testes de integração possuem isolamento com dependências de serviços externos, utilizando dados fake quando necessário testar a interface com esses serviços.
19. Integração Testes de integração são mais utilizados para testar o comportamentos de uma funcionalidade, diferente dos testes de unidade que focam mais em funções/lógicas específicas e dos testes de ponta a ponta que testam o sistema como um todo. São conhecidos também como testes de componentes ou de serviços.
20. O que já existe para testes de unidade e integração?
21. E o TDD?
22. TDD TDD (Test Driven Development) que traduzindo fica como Desenvolvimento orientado a testes. É uma prática de desenvolvimento de software. “TDD é uma disciplina, e isso significa que não é algo que vem naturalmente” - Harry Percival
23. TDD TDD x Testes unitários Você pode escrever testes unitários seguindo o TDD, mas nem todo teste será TDD . TDD é uma das práticas que pode ser utilizada para escrever testes, mas não é a única e não deve ser tratado como se fosse.
24. E o BDD?
25. BDD BDD (Behaviour Driven Development) que traduzindo fica como Desenvolvimento orientado por comportamento. É uma prática de desenvolvimento de software. BDD é uma técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando no comportamento da aplicação.
26. Testes ponta a ponta Dublês
27. Pirâmide
28. ponta a ponta Teste de ponta a ponta refere-se a um tipo de teste de software que envolve testar o fluxo de uma aplicação do início ao fim. O objetivo é replicar cenários reais de usuários para que o sistema possa ser validado quanto à integração e integridade dos dados. Testes unitários Testes de interface
29. ponta a ponta Diferente dos testes unitários e de integração, os testes de ponta a ponta na maioria se comunica com as dependências externas, para conseguir garantir que o fluxo todo está funcionando. São os testes que levam mais tempo, tanto para escrever quanto para executar e por isso geralmente cobrem mais os casos de caminho feliz dos fluxos. São conhecidos também como testes funcionais, de aceitação ou de fluxo
30. O que já existe para testes ponta a ponta?
31. Escopo de cada teste
32. Doubles / Dublês
33. Doubles / dublês Às vezes se torna difícil testar de forma automatizada uma aplicação, pois isso depende de outros ambientes que não podem ser usados no ambiente de testes. Para isso existe o Test Double, que é qualquer objeto que finge ser um real para fins de testes. A palavra double remete a Dublê de Cinema.
34. A dependência ainda não está disponível Comportamentos mais complexos de realizar em um ambiente real Maior controle e visibilidade do comportamento realizado no teste Para não sobrecarregar dependências externas com chamadas de testes Quando dublês são úteis? Para não poluir dependências externas com dados de testes automatizados
35. Dummies Fakes Spies Stubs Mocks Tipos de dublês var TaskManager = function(){ var taskList = []; return { addTask: function(task){ taskList. push(task); }, tasksCount: function(){ return taskList.length; } } } // Teste describe('add task', (assert) => { it('Exemplo de objeto Dummy' , function(){ var DummyTask = function(){ return {} }; var taskManager = new TaskManager(); taskManager. addTask(new DummyTask()); taskManager. addTask(new DummyTask()); assert.equal(taskManager.tasksCount(), 2); }) })
36. Dummies Fakes Spies Stubs Mocks Tipos de dublês var fakeDateService = { now: function() { return new Date('2020-02-02'); } } it("retorna idade em dias" , function() { let maria = new Cliente( 'Maria da Silva', new Date("2010-01-26") ) idade = maria.getIdade( 'dias', fakeDateService) expect(idade).toEqual( 3659); });
37. Dummies Fakes Spies Stubs Mocks Tipos de dublês @Test public void whenSpyingOnList_thenCorrect() { //Assert List<String> list = new ArrayList<String>(); List<String> spyList = Mockito.spy(list); //Act addUsers(spyList) Mockito.verify(spyList).add( "one"); Mockito.verify(spyList).add( "two"); //Assert assertEquals(2, spyList.size()); }
38. Dummies Fakes Spies Stubs Mocks Tipos de dublês describe('UsersController getAll()' , () => { it('should return a list of users' , () => { const expectedResponse = [{ id: 1, name: 'John Doe', email: 'john@mail.com' }]; const findAll = sinon.stub(Database, 'findAll'); findAll.withArgs( 'users').returns(expectedResponse); const usersController = new UsersController(Database); const response = usersController.getAll(); expect(response).to.be.eql(expectedResponse); findAll.restore(); }); });
39. Dummies Fakes Spies Stubs Mocks Tipos de dublês describe('UsersController getAll()' , () => { it('should call database with correct arguments' , () => { const databaseMock = sinon.mock(Database); databaseMock. expects('findAll'). once(). withArgs('users'); const usersController = new UsersController(Database); usersController.getAll(); databaseMock.verify(); databaseMock.restore(); }); });
40. Qualidade vai além da pirâmide de testes
41. Cobertura de código Análise estática de código Análises de segurança Documentação de código QUALIDADE DE SOFTWARE O que mais tem por aí? ….
42. Muitas ferramentas Por que praticamos testes? Por que usamos linters? Por que documentamos? ...
43. O que vcs acham? Por que praticamos testes? Por que usamos linters? Por que documentamos? ...
44. Conclusão Testes são uma de outras várias ferramentas que nos ajudam a: • Garantir nossa sanidade: manutenibilidade do código; • Ajuda na arquitetura; • Facilitam o trabalho em time; • Ajudam a cumprir requisitos de negócio; • Impactam na qualidade da nossa aplicação;
45. Gostaria de saber mais sobre outros patterns em testes como ice-cream-cone, outros