Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CPBR8: WTF to Test

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.

Edson Hilios

January 27, 2015
Tweet

More Decks by Edson Hilios

Other Decks in Programming

Transcript

  1. WTF to Test
    Qualidade de software na prática
    4 de Fevereiro 2015
    #qa #tdd #agile #ci #dev

    View Slide

  2. Edson Hilios
    Engenheiro @ Centro de Inovação Telefónica | Vivo
    http://edson.hilios.com.br

    View Slide

  3. View Slide

  4. Time ágil

    View Slide

  5. Processo
    1. Aprovação da história
    2. Desenvolvimento
    3. Code review
    4. UX review
    5. Test review
    6. Aceitação

    View Slide

  6. Quem aqui testa código?

    View Slide

  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.

    View Slide

  8. Faça direito da primeira vez!
    – Crosby, P. B.

    View Slide

  9. O mito do super-programador!
    https://www.youtube.com/watch?v=0SARbwvhupQ

    View Slide

  10. Uma questão de processo
    ● Critérios de aceitação
    ● Test case
    ● Code review
    ● Test review
    ● Testes manuais
    ● Testes automáticos

    View Slide

  11. Curva de produtividade
    Ínicio do projeto
    (poucas features)
    Maturação do projeto Muito tempo de projeto
    (muitas features)
    Produtividade
    Tempo

    View Slide

  12. WTF#1
    25 minutos de exec de testes!
    12.326,228 seconds

    View Slide

  13. Desenvolvimento "ágil"!
    12.326,228 segundos são:
    3 horas 42 min 43 seg e 228 ms

    View Slide

  14. View Slide

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

    View Slide

  16. ● Controllers / Activities
    ● Views / Fragments
    ● Models
    ● Rotas
    ● Serviços globais
    Software padrão 2015

    View Slide

  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?

    View Slide

  18. Só que você não está testando a sua
    aplicação, e sim o framework!

    View Slide

  19. 0
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    View test
    test('element should render correctly', function() {
    var template =
    '' +
    '' +
    '';
    expect(element.html()).to.be.equal(template);
    });

    View Slide

  20. Cuidado para não gerar testes que no fundo não testam nada

    View Slide

  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.

    View Slide

  22. Mocks
    Fixtures
    ...
    Controller
    Views
    Models
    Scripts
    Resultado
    renderizado
    Testes E2E
    Prepara ambiente Executa pré-condições Executa teste

    View Slide

  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).

    View Slide

  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.

    View Slide

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

    View Slide

  26. Automatização E2E
    ● Selenium
    ● Protractor
    ● Sikuli Script

    View Slide

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

    View Slide

  28. Alterou o componente da view e todos os testes quebram

    View Slide

  29. 0
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    Teste E2E automatizado
    startApp();
    # Login
    clickLink('login');
    fill('Usuario', '[email protected]');
    fill('Senha', '1234');
    clickButton('Login');
    # Pedidor
    clickLink('Meus pedidos');
    findText('Pedido 1', 'Pedido 2', ...);
    findText('Status: Aprovado');
    findText('Status: Em andamento');

    View Slide

  30. Testes E2E geralmente são lentos
    ...e são executados na nuvem

    View Slide

  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
    ● ...

    View Slide

  32. Mas como manter a qualidade sem testar?

    View Slide

  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

    View Slide

  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!

    View Slide

  35. De repente sua UI...

    View Slide

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

    View Slide

  37. Owwwwww!!!

    View Slide

  38. Visual diffs

    View Slide

  39. Ferramentas UI/E2E
    ● Huxley (facebook)
    ● Dpxdt (Google)
    ● Wraith (BBC)
    ● PhantomCSS
    ● ImageMagick

    View Slide

  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.

    View Slide

  41. Regra do dedão
    Testes, assim como funcionalidades, tem que
    ter prioridade e objetivo, que representem os
    requisitos dos stackholders.

    View Slide

  42. Cenário ideal
    ● Caminho critíco coverage de 100%
    ● Teste de formulários
    ● Smoke test
    ● Regressão de layout
    ● 1 bug = 1 teste

    View Slide

  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.

    View Slide

  44. Tks!
    Twitter: @hilios
    Site: http://edson.hilios.com.br
    Apresentação: http://speakerdeck.com/hilios
    GitHub: http://github.com/hilios

    View Slide