https://media.blubrry.com/hipsterstech/content.blubrry.com/hipsterstech/hipsters_051_testes.mp3Podcast: Play in new window | Download | Embed RSS | More Compartilhar Assinar Testes Automatizados – Hipsters #51 04/07/2017 / agilidade Podcast programação / 59 Comentários 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: Paulo Silveira, host do Hipsters e que edita código no ftp Mauricio Linhares, o cohost da treta Mauricio Aniche, doutor em Engenharia de Software pela USP e pesquisador em TU Delft Links: Livro do Mauricio Aniche na Casa do Codigo de Testes Automatizados e um de TDD com Java Diferença entre Unidade, Integração e Sistema, do Mauricio Aniche TDD não é bala de prata, do Aniche também TDD e a influência no acoplamento e coesão Opiniões polêmicas do DHH sobre TDD Uma síntese sobre TDD com 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 Relacionado
What for? - 0 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”. Responder
Claudenir Freitas - 0 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? Responder
Bruno Paschoali - 0 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. Responder
Claudenir Freitas - 0 @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? Responder
Bruno Paschoali - 0 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. Responder
Maurício Linhares - 0 É, no geral parsing de JSON é bem rápido, tem que ser um negócio muito grande pra fazer muita diferença. Responder
Bruno Paschoali - 0 Pois é, Maurício. Eu ainda mudaria sua frase para “um negócio muito grande para fazer ‘alguma’ diferença” rs.
Claudenir Freitas - 0 @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 - 0 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!
Ednaldo Dilorenzo - 0 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. Responder
Alexandre Aquiles - 0 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 Responder
Ednaldo Dilorenzo - 0 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. Responder
Bruno Paschoali - 0 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. Responder
Maurício Linhares - 0 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. Responder
Dilnei Cunha (Aix) - 0 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 🙂 Responder
Paulo Silveira - 0 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. Responder
Lucas Palma Stabile - 0 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. Responder
Maurício Linhares - 0 Isso é bem triste mesmo, felizmente eu dei sorte e o professor mostrou testes com jUnit dentro do Eclipse na época da faculdade ainda 😀 Responder
Lucas Palma Stabile - 0 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. Responder
Bruno Paschoali - 0 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. Responder
Lucas Palma Stabile - 0 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. Responder
André Kauling Justi - 0 foi falado ali sobre alguns treinamentos de teste? pode passar os links?? queria treinamentos de teste para desenvolvedores Responder
Luiz Costa - 0 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? Responder
Aline De Farias Lisboa - 0 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. Responder
Camelo Rodoviário - 0 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 :/ Responder
Aline De Farias Lisboa - 0 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. Responder
Luiz Costa - 0 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 - 0 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 - 0 É 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. Responder
Aline De Farias Lisboa - 0 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. Responder
Maurício Linhares - 0 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. Responder
Aline De Farias Lisboa - 0 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. Responder
Camelo Rodoviário - 0 Qual a ferramenta que citaram que cria testes de unidade automaticamente no Java? Ego Suit? nao achei nada parecido no google :/ Responder
Mariana Elisa - 0 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… 😉 Responder
Camelo Rodoviário - 0 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 :/ Responder
Fabrício Cabral - 0 Não é a ferramenta citada no podcast, mas achei esta: https://randoop.github.io/randoop/ Testa aí e vê o que você acha. Responder
Luiz Pansarini - 0 que delicia de Podcast! Mas ainda acho que falta um sobre Service Desk, Automação de Processos e Deploy! Abs Responder
Henrique Silva - 0 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. Responder
Robson Bittencourt - 0 Qual o nome da ferramenta que altera o fonte para ver se os testes quebram? Responder
Maurício Linhares - 0 Cada linguagem tem a sua ferramenta, mas o nome do método é mutation testing: https://en.wikipedia.org/wiki/Mutation_testing Responder
Deyvid Nascimento - 0 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? Responder
Tiago César - 0 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. Responder
JUNIOR FERREIRA - 0 Perfeito, Clinte tem que saber que software não é macdonalds pato Donald. . Responder
Beto_Caldas - 0 Não consigo entender e nem encontrar o nome desse projeto que ele cita aos 19:40, alguém tem um link do projeto? Responder
