Slide 1

Slide 1 text

Trilha de Testes

Slide 2

Slide 2 text

Testes automatizados

Slide 3

Slide 3 text

Teste de software

Slide 4

Slide 4 text

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”

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Testes automatizados

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Código Interface O que testar?

Slide 9

Slide 9 text

Código Interface O que testar?

Slide 10

Slide 10 text

Como automatizar?

Slide 11

Slide 11 text

Ferramentas Existem diversas ferramentas no mercado que facilitam a automação dos testes de software

Slide 12

Slide 12 text

SHOW ME THE CODE https://github.com/inajaraleppa/exemplos-teste

Slide 13

Slide 13 text

Testes unitários e integração

Slide 14

Slide 14 text

Pirâmide de testes

Slide 15

Slide 15 text

Pirâmide

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

O que já existe para testes de unidade e integração?

Slide 21

Slide 21 text

E o TDD?

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

E o BDD?

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

Testes ponta a ponta Dublês

Slide 27

Slide 27 text

Pirâmide

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

O que já existe para testes ponta a ponta?

Slide 31

Slide 31 text

Escopo de cada teste

Slide 32

Slide 32 text

Doubles / Dublês

Slide 33

Slide 33 text

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.

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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); }) })

Slide 36

Slide 36 text

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); });

Slide 37

Slide 37 text

Dummies Fakes Spies Stubs Mocks Tipos de dublês @Test public void whenSpyingOnList_thenCorrect() { //Assert List list = new ArrayList(); List spyList = Mockito.spy(list); //Act addUsers(spyList) Mockito.verify(spyList).add( "one"); Mockito.verify(spyList).add( "two"); //Assert assertEquals(2, spyList.size()); }

Slide 38

Slide 38 text

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(); }); });

Slide 39

Slide 39 text

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(); }); });

Slide 40

Slide 40 text

Qualidade vai além da pirâmide de testes

Slide 41

Slide 41 text

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í? ….

Slide 42

Slide 42 text

Muitas ferramentas Por que praticamos testes? Por que usamos linters? Por que documentamos? ...

Slide 43

Slide 43 text

O que vcs acham? Por que praticamos testes? Por que usamos linters? Por que documentamos? ...

Slide 44

Slide 44 text

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;

Slide 45

Slide 45 text

Gostaria de saber mais sobre outros patterns em testes como ice-cream-cone, outros

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

49