Testes Automatizados – Hipsters #51

Vale a pena testar sua aplicação? De forma automatizada? Antes mesmo de escrever o código principal? Testes, TDD, automação e qualidade são os tópicos dessa conversa que saiu faz tempo do hipsterismo para o mainstream.

Participantes:

Links:

Produção e conteúdo:

  • Alura Cursos online de Tecnologia
  • Caelum Ensino e Inovação

Edição e sonorização: Radiofobia Podcast e Multimídia

Leave a Reply

59 Comentários

  1. What for?

    Bom dia, o link para “Diferença entre Unidade, Integração e Sistema”, está errado e apontando para o artigo “TDD não é bala de prata”.

  2. Vou me embora pra Pasárgada

    Hipters de hoje é uma boa ideia.

  3. Claudenir Freitas

    A-NI-MAL!!! Só uma dúvida, falando sobre API REST – HTTP – JSON – Piramede de Testes – contexto ágil – tempo – eis o ponto! JSON é o formato mais leve que conheço até então e o mais utilizado dentre algumas pessoas que conversei nesta industria vital, pergunta: quero fazer um teste de integração para testar uma solução com alguns serviços, se o formato é JSON logo é Javascript, logo não precisaria ficar ‘parseando’ tudo que é trafegado… estou viajando lindo ou acham que faz sentido?

    • Bruno Paschoali

      Claudenir, sua pergunta ficou bem confusa e vou responder com base no que entendi.

      Quando falamos de testes, independe da tecnologia utilizada. Não importa se chamaremos um serviço que cospe o retorno em JSON, ou se o retorno é XML. Existem parses pra diversos formatos e não é isso que vai limitar se o teste é fácil ou bom.

    • Claudenir Freitas

      @brunopaschoaliregis:disqus e @mauriciolinhares:disqus joguei palavras chaves no inicio pra ficar mais claro, mas parece que não ajudou muito… enfim, na piramede de testes (não consegui inserir o link, o Disqus não ajudou), os testes tendem a ficar mais caros e lentos a medida que você vai implementando em cada camada, isso num contexto de API REST trafegando JSON falando especificamente na camada de Service e UI, dado as circunstancias tempo, dinheiro, esforço, agilidade e outros… eis o ponto, JSON é um estrutura de dados em Javascript, logo não tem o custo de ficar ‘parseando’ o que é trafegado, já em outras linguagens sim, Java usando JAXB (exemplo), logo se você elimina esse parse você ganha tempo, minimo que seja, se forem muitos testes (tende a ser), essa variação de teste pode ser considerável, eis a minha pergunta, entendem? Consegui ser claro?

      • Bruno Paschoali

        Bom, entendi sim, mas não sei se realmente tem esse ganho e se chega a ser considerável. Será? Talvez. Nunca vi nada a respeito. O ideal era testar dois cenário iguais, apenas mudando a tecnologia e executar a rotina milhares de vezes.

          • Bruno Paschoali

            Pois é, Maurício. Eu ainda mudaria sua frase para “um negócio muito grande para fazer ‘alguma’ diferença” rs.

          • Claudenir Freitas

            @brunopaschoaliregis:disqus há diferença, isso é fato! Independente da linguagem, há o ‘parser’, então tem custo, pequeno que seja mas tem. Como comentei com o @mauriciolinhares:disqus , vou fazer um teste e depois apresento as métricas… valeu a atenção!

          • Claudenir Freitas

            exato @mauriciolinhares:disqus , se o volume de dados é grande (e tende a ser no contexto que vivenciamos) qualquer milisegundos (tem gente falando na escala de nano segundos) é muito vantajoso… vou fazer um teste de carga numa API simples, e depois compartilho as métricas deste teste de performance. Valeu a atenção!

  4. Ednaldo Dilorenzo

    Um grande problema que vejo na parte de testes principalmente de integração é testar performance de sistemas, uma vez que testar performance em um ambiente de testes não garante a performance em ambiente de produção. Outro ponto é que manter um ambiente semelhante ao de produção apenas para testes, geralmente é muito caro.

    • Muito interessantes as considerações, Ednaldo.

      Fica complicado determinar um valor EXATO para o tempo de resposta ideal. Por isso, os requisitos de performance deveriam ser definidos de maneira estatística, tipo: 20 ms +/- 5. Um teste, então, verificaria se o tempo medido está dentro desse intervalo.

      A questão do ambiente é fundamental. A massa de dados no BD, a rede, os servidores, etc, influenciam e deveriam emular o ambiente de produção. Acho que o que é mais comum é preparar esse ambiente pra testes a cada x ciclos de entrega (sprints) e não continuamente. Com cloud e infra as code (Chef, Puppet, Ansible, Docker), criar os ambientes fica mais fácil. A mesma reflexão vale para testes de carga e de stress.

      Uma coisa fundamental é criar monitoramentos em produção. Como o Linhares menciona no episódio, algum código que verifica se funcionalidades cruciais estão OK. Outra coisa é registrar um log dos tempos de resposta em produção e analisá-los de tempos em tempos.

      O Danilo Sato, da Thoughtworks, deu uma palestra bem bacana no Agile Brazil 2013 sobre o que ele chama de “Requisitos Transversais”:
      https://www.slideshare.net/dtsato/princpios-e-prticas-para-lidar-com-requisitos-nofuncionais-em-desenvolvimento-de-software

    • Ednaldo Dilorenzo

      Legal Alexandre, hoje em dia nem considero tanto a complexidade da montagem do ambiente (apesar de que nem todo mundo usa cloud, Docker, etc.), mas digo o custo mesmo. Trabalhei em uma grande empresa em que realizavamos testes de carga no ambiente de produção apenas na primeira release, pois já era o ambiente real. Só que nos releases subsequentes já não tínhamos como fazer isso, uma vez que o ambiente de produção era grande e complexo.

      Mesmo nos clouds da vida, imagina que vc faz um e-commerce e quer simular se seu sistema está pronto para receber uma pancada de solicitações no Natal usando um ambiente de testes do próprio cloud. Aposto que vai te custar uma fortuna. No meu ver seria a abordagem ideal, mas nem sempre é viável, principalmente financeiramente.

    • Bruno Paschoali

      Bela discussão. Custo deve impedir muita equipe de fazer teste de carga em produção. Mas, como o Alexandre disse, logs ajudam bastante. Utilizar bem os logs com cronômetros já ajuda muito, embora isso não vá prevenir de algum crash da aplicação.

    • Teste de performance só dá pra ver baseline e antes de ir pra produção, pro resto tem que coletar métricas mesmo e tentar extrapolar, testes de performance podem ajudar a descobrir até onde a plataforma atual vai mas é difícil de manter eles úteis no longo prazo.

  5. Achei muito legal o podcast de testes, na verdade penso isso de todos 🙂 Só penso que poderiam ter falado não somente de TDD mas também incluir BDD e o ATDD/STDD. Parabéns Paulo! Estou viciado nos podcasts 🙂

    • Paulo Silveira

      valeu Dilnei! a gente tem tentado pegar menos assuntos de uma vez só. se fossemos colocar BDD e muito mais, ficaria bem complicado pra quem está ouvindo falar de testes agora.

  6. Lucas Palma Stabile

    Ae, esperava por este tema aqui! De Fato, o “mindset” que temos ao pensar com TDD é bem interessante ao desenvolver códigos mais facilmente testados. Fiz faculdade de ADS de 3 anos, e não sei se foi algo deste curso específico, mas senti muita falta de já aprender a programar com testes na faculdade, apenas estudamos testes nas matérias teóricas de engenharia de software, que comentaram sobre testes caixa preta e branca.

    • Isso é bem triste mesmo, felizmente eu dei sorte e o professor mostrou testes com jUnit dentro do Eclipse na época da faculdade ainda 😀

      • Lucas Palma Stabile

        Eu poderia ter ido atrás disso e talvez falado com professores para pelo menos comentassem isso em alguma aula, mas não pensei nisso na época. Enfim, sempre bom procurar outros conhecimentos também.

    • Bruno Paschoali

      Lucas, isso é uma realidade de muitos cursos e faculdades no Brasil. O resultado é muita empresa no Brasil ter pouco ou simplesmente não ter nada de testes, por conta de desenvolvedores que não conhecem e empresas que não se importam. Complicado.

      • Lucas Palma Stabile

        Já vi isso mesmo, e é bizarro. Sistemas grandes sem nada ou praticamente nada de testes, além do teste manual e que dito pelo Maurício neste podcast, a cada novo check-in ou deploy, tecnicamente não vale de mais nada para garantir a qualidade do software. É basicamente acreditar que ainda está funcionando ou esperar novos bugs abertos pelos clientes.

  7. André Kauling Justi

    foi falado ali sobre alguns treinamentos de teste? pode passar os links?? queria treinamentos de teste para desenvolvedores

    • Camelo Rodoviário

      Na caelum tem o Fj-22, que ensina usar o Junit.

    • Paulo Silveira

      atualizei o post com jaba pros cursos nossos 🙂

  8. Luiz Costa

    Como sempre, temas que são úteis no dia a dia. Dúvida, Onde os cenários mudam constantemente, quem deveria escrever os testes, o desenvolvedor ou a equipe de testes?

    • Aline De Farias Lisboa

      Eu acredito q todos deveriam escrever a um certo nível, pois os testes de unidade não garantem 100% da qualidade do sistema, ou todos os pontos de erro do sistema. Assim como os testes de integração também não garantem.
      Os testes de sistema na maioria das vezes são feitos pela equipe de testes/qualidade, mas infelizmente não tenho visto um movimento no Brasil de equipes de qualidade migrando para testes automatizados.

      • Camelo Rodoviário

        Mas a equipe de QA tem esse conhecimento? de escrever testes automatizados? Sou desenvolvedor/fornecedor e quando entrego um software para equipe de QA do cliente, eles mal sabem fazer consultas na base para ter massa de testes, imagina então escrever os testes :/

        • Aline De Farias Lisboa

          Mas é exatamente essa mudança que está acontecendo lá fora. Os analistas de teste que não entendem de programação estão perdendo espaço e as áreas de qualidade estão sendo substituídas por áreas de automação de testes. Mesmo que elas coabitem, um analista de qualidade que mal sabe fazer uma consulta na base vai perdendo espaço no mercado.
          Fico muito triste em ver que aqui no Brasil ainda não estamos caminhando direito para isso, mas vendo o movimento lá de fora vejo q um analista de qualidade tem que se atualizar ainda mais em programação para conseguir falar com todas as equipes necessárias.

          • Luiz Costa

            Isso mesmo Aline, trabalho fora do Brasil e por aqui, a equipe de QA desenvolve os testes automatizados de maneira bem apropriada.

          • Aline De Farias Lisboa

            Trabalho em uma empresa bem pequena, somos em 6, sou a única QA… acabei acompanhando várias páginas de testers fora do Brasil, fico impressionada com o que eles falam.

        • Bruno Paschoali

          É bem o que a Aline comentou. O tester de hoje tem que saber programar pra ganhar espaço. A grande massa de testes, pra mim, é responsabilidade da equipe de testes. Contudo, teste de unidade o próprio desenvolvedor faz, outras etapas são divididas e algumas ficam só com a equipe de testes, que tem muito mais gabarito pra construir testes mais criativos.

  9. Aline De Farias Lisboa

    Por trabalhar diretamente com o tema eu estava esperando muito por esse podcast, mas foi muito direcionado à área do desenvolvedor e pouco na área de qualidade.
    Acompanho o mercado americano e europeu onde existe todo um movimento de mudança das áreas de qualidade de software para grandes áreas de automação que trabalham diretamente com a área de desenvolvimento.
    Vejo bem pouco disso no Brasil e gostaria muito q isso fosse abordado por podcasts brasileiros.
    Existe um podcast específico só para automação de testes que se chama “TestTalks”.
    Aguardo por um podcast voltado para a área de qualidade, que cada vez mais tem muito mais de desenvolvimento d que os velhos testes manuais.

    • Opa Aline, acho que a questão é mais porque não parece ser mais muito comum ter áreas de qualidade, já fazem alguns anos que não trabalho em lugares que tenham. Na DigitalOcean, por exemplo, não temos uma área de qualidade, equipes são responsáveis por toda automação de testes e avaliação de estados das aplicações que colocam em produção, não existem outras equipes envolvidas.

      • Aline De Farias Lisboa

        Pode ser. Trabalho em uma empresa muito pequena e só consigo me basear pelo que eu vejo em blogs e podcasts.
        Mas eu super recomendo o blog e o podcast do testtalks: https://joecolantonio.com/testtalks/
        Ele consegue chamar bastante gente da área, que agora eles até se chamam de engenheiros de automação, que basicamente automatizam testes no sistema.

  10. Camelo Rodoviário

    Qual a ferramenta que citaram que cria testes de unidade automaticamente no Java? Ego Suit? nao achei nada parecido no google :/

    • Mariana Elisa

      Junit, eles citaram no começo. Não sei se era isso que vc quis dizer. Ele não cria o teste de unidade automatico, ele “roda”. Vc pode usar ele dentro do Eclipse… 😉

      • Camelo Rodoviário

        Sim, mas la por volta dos 30:20, eles citam uma ferramenta que cria testes de unidade automaticamente, e se a classe está bem desenhada, os testes são gerados facilmente… eu não entendi o nome nem achei link para essa ferramenta :/

  11. Gabriel Prates

    Você testa se o teste do código testado é testável?
    #zofe8

  12. rogeriowd7

    Façam um PodCast sobre certificações !!

  13. Luiz Pansarini

    que delicia de Podcast!

    Mas ainda acho que falta um sobre Service Desk, Automação de Processos e Deploy!
    Abs

  14. Muito legal, na empresa em que colaboro, a gente chegou a mudar o requisito da chamada de uma vaga, de TDD para Testes Automatizados, depois de uma discusão a respeito do assunto no slack, fiquei feliz de ver que nosso pensamento está alinhado com o que foi passado nesse podcast.

  15. Deyvid Nascimento

    Cara, testes é uma parada punk, uma situação real, cliente me pediu uma funcionalidade, desenvolvi ela em 1 hora e fiquei 4 horas criando o teste dela, quando mostrei para o cliente ele mudou tudo, e precisava pra ontem, aí os testes da minha aplicação já era, como agir?

    • Aí é um problema de gestão e não especificamente do TDD. Talvez a empresa deva estudar a adesão a uma metodologia ágil. Usando Scrum, por exemplo, com um product owner ao lado do cliente, seria possível se antecipar a isso.

      • JUNIOR FERREIRA

        Perfeito, Clinte tem que saber que software não é macdonalds pato Donald. .

  16. Beto_Caldas

    Não consigo entender e nem encontrar o nome desse projeto que ele cita aos 19:40, alguém tem um link do projeto?

Next ArticleA vez do Ruby on Rails - Hipsters #52