CPBR8: WTF to Test

456d07b3f7a1ab66502e232fd9b1d378?s=47 Edson Hilios
January 27, 2015

CPBR8: WTF to Test

Apresentação feita na CampusParty BR Edição 8 em 4 de Fev, 2015.

Insights de qualidade de software na prática, de um time internacional de desenvolvimento ágil, mas o que testar, como testar e principalmente como garantir um app de qualidade para o seu cliente mantendo o desenvolvimento legal.

456d07b3f7a1ab66502e232fd9b1d378?s=128

Edson Hilios

January 27, 2015
Tweet

Transcript

  1. 1.

    WTF to Test Qualidade de software na prática 4 de

    Fevereiro 2015 #qa #tdd #agile #ci #dev
  2. 3.
  3. 5.
  4. 7.

    Por quê testar? • Manter sua sanidade mental; • Ajuda

    a encontrar/resolver de bugs; • Facilita refatoração; • Documentação; • Melhora o design do código; TL; DR: Garante um trabalho com qualidade.
  5. 10.

    Uma questão de processo • Critérios de aceitação • Test

    case • Code review • Test review • Testes manuais • Testes automáticos
  6. 11.

    Curva de produtividade Ínicio do projeto (poucas features) Maturação do

    projeto Muito tempo de projeto (muitas features) Produtividade Tempo
  7. 14.
  8. 15.

    0 1 2 3 4 5 6 7 8 9

    10 Test unitario test('fibonacci function', function() { expect(fibonacci(0)).to.be(0); expect(fibonacci(1)).to.be(1); expect(fibonacci(2)).to.be(1); expect(fibonacci(3)).to.be(2); expect(fibonacci(2)).to.be(3); expect(fibonacci(2)).to.be(5); // ... expect(fibonacci(10)).to.be(55); });
  9. 16.

    • Controllers / Activities • Views / Fragments • Models

    • Rotas • Serviços globais Software padrão 2015
  10. 17.

    Test case • Faz a chamada do modelo correto? •

    Expõe as váriavies corretas? • Renderiza o template correto? • Variaveis são exibidas no template?
  11. 19.

    0 1 2 3 4 5 6 7 8 9

    10 View test test('element should render correctly', function() { var template = '<form>' + '<input type="email">' + '</form>'; expect(element.html()).to.be.equal(template); });
  12. 21.

    Use com moderação Testes unitários só são uteis quando trabalham

    isolados, isto é, com poucas ou nenhuma dependencia e interação simples.
  13. 22.

    Mocks Fixtures ... Controller Views Models Scripts Resultado renderizado Testes

    E2E Prepara ambiente Executa pré-condições Executa teste
  14. 23.

    Fixtures e mocks Fixtures são os dados iniciais do seu

    app, necessários para a execução dos testes. Mocks são respostas ficticias para uma determinada função (ex: resposta de uma API).
  15. 24.

    Test case Como um usuário logado quando entro em LiveTV,

    eu vejo a lista de canais disponiveis, com nome, numero do canal, o programa atual e o próximo programa com hora de inicio e fim.
  16. 25.

    0 1 2 3 4 5 6 7 8 9

    10 Teste E2E beforeTest('element should render', function() { loginAs('userWithHBO'); }); test('element should render correctly', function() { var channel = 'HBO HD'; var currentShow = 'Game of Thrones'; expect(element.html()).contains(orderNum); expect(element.html()).contains(status); });
  17. 27.

    0 1 2 3 4 5 6 7 8 9

    10 Teste E2Fail test('element should render correctly', function() { expect(element.html()).have.element('h1.main'); expect(element.html()).have .element('ul.channel-list'); var channelList = element.html().find('ul.channel-list'); expect(channelList).to.have.length.gt(0); expect(channelList.html()) .contains('<strong>HBO HD</strong>') });
  18. 29.

    0 1 2 3 4 5 6 7 8 9

    10 Teste E2E automatizado startApp(); # Login clickLink('login'); fill('Usuario', 'john@host.com'); fill('Senha', '1234'); clickButton('Login'); # Pedidor clickLink('Meus pedidos'); findText('Pedido 1', 'Pedido 2', ...); findText('Status: Aprovado'); findText('Status: Em andamento');
  19. 31.

    O que testar? Teste apenas o caminho crítico do seu

    negócio e/ou cliente: • Pipeline de pagamento • Registro de usuários • Regra de negócio importante • Login • ...
  20. 33.

    Visita todos as views de um app procurando por erros

    comuns: • Campo vazio • Erro nos scripts • Página não carregou • Nenhuma imagem quebrada • ... Smoke test
  21. 34.

    0 1 2 3 4 5 6 7 8 9

    10 links = ['/'] visited = [] # Visita todos os links e verifica se há erros while len(links) > 0: uri = links.pop(0) visited.append(uri) assert page_is_ok(uri) for a in get_all_links(): if a.get('href') not in visited: links.append(a.get('href')) One test to rule them all!
  22. 36.

    0 1 2 3 4 5 6 7 8 9

    10 Teste de interface test('element should render correctly', function() { expect(element).to.have .css('background-color', '#ff0000'); expect(element).to.have .css('font', 'Arial'); ... });
  23. 40.

    A falácia do Code Coverage Code coverage como métrica de

    qualidade é uma mentira, pois nos leva a crêr que escrever um teste por si só, já é o suficiente.
  24. 41.

    Regra do dedão Testes, assim como funcionalidades, tem que ter

    prioridade e objetivo, que representem os requisitos dos stackholders.
  25. 42.

    Cenário ideal • Caminho critíco coverage de 100% • Teste

    de formulários • Smoke test • Regressão de layout • 1 bug = 1 teste
  26. 43.

    A definição de qualidade é conformidade com os requerimentos do

    projeto (tanto do ponto de vista de produto quanto do consumidor) – Crosby, P. B.