M1: Olá, pessoal. Bom dia, boa tarde, boa noite. Vamos começar mais um episódio dos Agilistas. Hoje eu estou aqui com três arquitetos sêniors da DTI: o Felipe Chagas. [00:00:11]

Felipe Chagas: Oi, pessoal.

M1: Mateus Araújo.

Mateus Araújo: Bom dia, pessoal.

M1: E uma participação que já é constante aqui, o Felipão.

Felipão: E aí, pessoal, beleza?

M1: Bom, o tema que a gente quer abordar aqui hoje está diretamente relacionado, de forma mais ampla, com um tema que gente abordou um tempo atrás num episódio do podcast que a gente chamou de Ignorância Intencional. Então, naquele episódio, a gente defendeu muito fortemente que as empresas, os executivos, o negócio, têm que entender cada vez mais o que significa ser digital, o que impede uma empresa de ficar digital, o que impede uma empresa de ficar ágil, para que a empresa realmente consiga prosperar nessa nova era. Então a nossa defesa é a de que hoje em dia os executivos e várias pessoas nas empresas são intencionalmente ignorantes em relação a esses assuntos, consideram que esses assuntos são muito técnicos, que não vale à pena entendê-los, e, mais do que não valer à pena entendê-los, elas, inclusive, impedem que esses assuntos sejam discutidos, porque, uma coisa que eu brinquei muito nesse episódio, se um cara chegar em uma apresentação para o negócio com termo técnico, a carreira dele está condenada na empresa. E, é claro, que uma empresa que vai começar a ser suportada por uma plataforma digital, que vai desenvolver muito software, que vai ter uma cultura de agilismo, tem que começar a não ter medo de certos termos. E, da mesma forma que os executivos que são admirados, os executivos digitais, entendem esses temas, a gente acredita que os executivos das empresas mais tradicionais que querem mudar têm que começar a fazer esse caminho. Então, a gente vai fazer uma série de episódios com esse pessoal, para trazer alguns termos, não que a gente vá falar “técnico demais”, mas também não vamos ter muito pudor. Eu já peço para o pessoal aqui para não ficar com muito pudor de falar alguma (palavra) [00:02:14]. E a gente queria começar falando de uma coisa que é importantíssima para alguém que quer ficar digital, que são os testes automatizados, então, é uma prática importantíssima, e é importante falar, porque se o negócio não entende isso, se quem toma a decisão de como gastar o dinheiro não entende isso, isso pode causar sérios impactos na possibilidade de a empresa ser ágil, na qualidade do que está sendo produzido, que é o que a gente vai explorar aqui. Então começo perguntando para vocês o que são os testes automatizados, no final das contas?

Mateus Araújo: Acho que, se você fizer essa pergunta para dez pessoas, você vai ouvir obter umas 15 respostas diferentes, provavelmente aqui mesmo a gente vai obter algumas visões um pouco diferentes. Bom, primeiro, acho que testes automatizados são código, então, eles fazem parte do código, eles são inerentes ao código. E, pensando um pouco sobre o que é engenharia de software, uma comparação bem clássica que tem entre a engenharia de software e outras engenharias clássicas é a de comparar um míssil teleguiado com uma catapulta. Uma catapulta seria as engenharias clássicas, a engenharia civil, a engenharia mecânica. Basicamente, você tem um alvo fixo, estático, você planeja o lançamento da catapulta, da esfera que vai lançar, você planeja, você lança e você torce para que chegue lá. No desenvolvimento de software, o nosso alvo é uma coisa móvel, é uma coisa que está se movendo, que é completamente dinâmica, que muda o tempo todo, e além disso, você tem diversos sistemas que impedem e tentam impedir esse míssil de chegar ao alvo. Então, a gente está falando de sistemas que são completamente flexíveis, sistemas que se adaptam, que devem ser resilientes a essas adversidades do ambiente, e sistemas que mudam com o tempo, que são evoluíveis. Uma das formas de a gente habilitar isso é através dos testes, porque os testes vão tentar acelerar o processo através do qual você valida se um software está certo ou não, se ele funciona ou não.

M1: Entendi. Então você está dizendo que os teste automatizados vão garantir, no exemplo seu, que aquele míssil está caminhando e está se adaptando ao que acontece de diferente.

Mateus Araújo: Sim, e em um contexto no qual a coisa muda bastante, que eu acho que é a principal diferença da engenharia de software para as outras engenharias.

Felipão: E principalmente se a correção de curso da evolução do software não está quebrando todo o trajeto já percorrido, não está invalidando o que já está construído, vamos dizer assim.

Felipe Chagas: Além de garantir que não está invalidando, você garante que o que está sendo feito, está sendo feito com uma qualidade superior, por alguns motivos que a gente vai elucidar, simplesmente pelo fato de que testes estão sendo realizados, estes estão sendo programados.

Mateus Araújo: Sim, com certeza. A gente percebe que códigos que são orientados a testes são códigos são mais fáceis de se manter, códigos mais fáceis de evoluir. Não só por ter o teste, mas a forma como o código é construído é, também, uma forma mais fácil de ser lida, é um código mais tranquilo de ser evoluído.

Felipe Chaga: Se você fizer um código que é muito difícil de ser testado, provavelmente esse código não está seguindo boas práticas. Então, entrando um pouquinho no detalhe, ele não vai estar tão modularizado, ele não vai estar tão desacoplado. E, para poder permitir que um teste seja feito nesse texto de código, ele vai ter que ter esse comportamento de modularizado, desacoplado, e isso vai estar garantindo que essa parte vai estar sendo bem feita.

M1: Interessante. Ou seja, quem já parte de uma prática que é orientada a testes, necessariamente, para poder fazer aqueles testes com eficiência, ele vai ter que conceber o software de uma forma mais limpa, mais clara, então ele vai se beneficiar disso também. É isso que você está falando?

Felipe Chagas: Isso, inclusive, é uma das dificuldades de a gente poder testar código legado. Porque, às vezes, o código não foi feito seguindo essas práticas, então, para poder criar o código em cima do código legado, é necessário reescrever alguns trechos dele.

Felipão: Sim, e uma definição de código legado bastante interessante é a de que qualquer código sem teste é um código legado.

Felipe Chagas: Sim, porque é aquela história, o teste auxilia o entendimento da regra de negócio do código. Então, um código que tenha teste, a gente pode dizer que o teste é quase uma documentação daquele trecho. A pessoa que vai ler um código começa lendo teste, porque o teste descreve o comportamento funcional que aquela unidade, aquele trecho precisa executar.

M1: E muito melhor do que uma documentação escrita, isolada. Porque se o teste for ficando ultrapassado, ele vai falhar. Então você vai ter que manter ele atualizado.

Felipe Chagas: Nesse sentido sim. O “muito melhor” acho um pouco complicado, porque, dependendo, ter outras documentações é importante. Mas a vantagem do teste é que se ele estiver ultrapassado ele vai quebrar. Porque, às vezes, as pessoas acham que só o teste substitui outros tipos de documentação, e não necessariamente.

Felipão: Ele é complementar.

Felipe Chagas: Exatamente.

M1: E por que que é, ou seja, vocês estão falando que é quase que, eu não sei a palavra seria óbvia, que o teste automatizado faz parte do (ciclo) [00:07:32] de desenvolvimento, não é uma coisa opcional. Mas a gente ainda percebe uma luta grande, por que que é tão difícil convencer o cliente, ou convencer os times, que tem que fazer teste automatizado, quais que são as visões suas nesse sentido?

Felipe Chagas: O teste fazer parte do ciclo de desenvolvimento é algo muito natural, só que nem sempre é visto assim. Então, eu gosto muito de uma analogia que é um cirurgião, um médico, ninguém pede para ele deixar de lavar a mão para ele poder fazer mais cirurgias ao longo do dia, mas pedem pros desenvolvedores deixarem de fazer teste, para poder entregar mais história. E deveria ser tão chocante quanto pedir para um cirurgião deixar de lavar a mão, porque as consequências no código são tão graves quanto.

M1: Vai dar uma infecção no código.

Felipe Chagas: Exatamente. Vai gerar doenças no código porque ele não foi feito com as melhores práticas, vai ter dificuldade de manutenção, enfim, uma série de consequências negativas que vem do fato da não realização dos testes. Então, o entendimento é, eu não estou fazendo uma história e depois vou fazer um teste. A história, para ela ser entregue, ela tem que ter um teste. Então, o definition of done dos times deveria contemplar os testes, não está pronto se não tem teste.

Felipão: Eu acho que isso tem muito a ver com aquilo que você comenta, acho que até no episódio da ignorância tensional, em que, eu acho que a área de negócio ainda tem muito incutida a ideia de que um backlog deve conter apenas features, e se você estiver features, aí você sim está gerando valor. É óbvio que nós temos que ter uma busca obstinada por geração de valor, mas o software que seja construído procurando obstinadamente esse valor, mas que não tem essa rede de proteção para que esse valor possa ser sustentando e, principalmente, que esse software orientado à geração de valor possa evoluir, se a gente não construir de proteção, a gente acaba correndo um risco muito grande de num futuro, como o Chagas comentou, esse software pegar uma infecção e não parar de pé mais.

M1: E tem um negócio. Eu lembro que no livro lá do Kent Beck, do (Csim Programme) [00:09:50], a premissa, não a premissa, um dos princípios que o Kent Beck coloca no começo do livro é assim: “vamos tornar a curva mudança plano, flat, ao contrário do curso de mudanças exponencial”, que tem em todo livro de engenharia de software. Para (essa montanha de coisa) [00:10:09] que você faz, mas uma das coisas é o teste automatizado, porque senão vai ser sempre muito custoso mudar. Aí o embrace change vai ser ficção.

Mateus Araújo: Eu acho que, além dessa questão de você conseguir fazer alterações mais rápidas, à medida que o código vai evoluindo com o tempo, é um benefício que se tem de maneira bem rápida, que se você tem um teste que não tem código, quando você vai colocar uma versão nova desse código em produção, leva-se muito tempo testando. Mas se você tem uma suíte de teste automatizados, você consegue muito rapidamente testar esse código, fazer esse teste de garantir que as regras do passado continuam válidas. Então, além de tornar a evolução do código mais fácil, colocar um código em produção se torna um processo mais fácil também, mais fácil e mais rápido. Então você consegue gerar valor mais rápido também com o teste.

M1: É, tem sentido econômico, vai conseguir retorno.

Mateus Araújo: Sim.

M1: A gente vai fazer um episódio sobre devotos, no qual isso vai ficar bem claro. Porque vai ser condição para vários dos indicadores de qualidade e de aceleração.

Felipe Chagas: É, os teste automatizados são um dos drivers para entrega contínua, então a gente não consegue ter entrega contínua se a gente não tem teste automatizado. Mas acho que a gente está falando muito das vantagens e desvantagens de não ter os testes, mas conceituar, porque às vezes fica uma mística em volta dos testes automatizados, e não tem mistério. Teste automatizados é um código que serve para validar o comportamento de outro código. Então vamos supor que eu tenha um código que somou dois números, eu posso fazer um teste automatizado que ele vai falar assim olha: se eu colocar dois e três, eu espero cinco, deu cinco? Deu. Então está funcionando. Aí, se eu colocar dois e três, eu não espero quatro, se der quatro, esse resultado é inesperado. Então ele nada mais é do que código testando código. E, às vezes, esse código, inclusive, vai ser mais complexo e maior do que o próprio código que ele está testando. Então, não é raro, você gastar mais tempo desenvolvendo um teste do que a própria feature em si. E isso parece uma absurdo, meu deus estou gastando tempo.

M1: Parece um contrassenso para quem olha de fora.

Felipe Chagas: Estou gastando tempo fazendo um código que não faz nada, fazendo um código para testar se você está fazendo seu trabalho direito. Mas como a gente vai ver, isso é muito válido para a frente do ciclo de vida do produto.

Felipão: Principalmente considerando a relação de custo de desenvolvimento do teste, e em situações como essa que você comentou em que a construção do código que testa às vezes é mais complicada do que a construção do código que faz. A gente já pode ver um primeiro resultado positivo de se ter uma suíte de teste unitárias, de integração, depois, acho que a gente pode conceituar cada tipo de teste automatizado, é, aonde a gente pode evitar a necessidade de uma grande ciclo de homologação que pode ser necessário envolver vários usuários, fazer teste de regressão. Então se você tem a sua suíte de teste muito bem escrita, você já tem uma segurança muito maior de entregar uma nova funcionalidade sem precisar fazer um teste e regressão, uma homologação muito grande. Então já fica muito óbvio o ganho, o retorno de um suíte de teste bem desenvolvida.

M1: Agora, quais são os tipos de testes que existem, porque tem teste unitário, teste de integração, existe um consenso sobre isso ou não?

Felipão: Na maior parte da literatura, igual o Mateus comentou aqui no início, a gente pode até divergir um pouco em relação à existência de mais ou menos tipos de testes automatizados, mas eu acho que os tipos mais básicos principais são os testes unitários, os testes de integração e teste de ui, que são testes de interface, vamos pegar esses três macrotipos de teste. E eu gosto muito, quando eu vou fazer um processo junto a um time, fazer uma análise arquitetural, de conceituar para o time, para sabre se a gente está construindo cada tipo de teste no limite da sua atribuição. Então o teste unitário, como o próprio nome já diz, ele testa a unidade, como o Chagas comentou, às vezes você uma operação matemática, a soma de dois números, às vezes a funcionalidade completa deveria somar, deveria multiplicar, deveria dividir, mas se você vai testar unitariamente, você testa a soma, depois testa a divisão, depois testa a multiplicação, de forma que você garanta que cada uma dessas unidades funcionem perfeitamente nos seus fluxos principais e de exceção. E um teste unitário, eu gosto de falar, aliás, em todo tipo de teste a gente deveria avaliar três grandezas, que seriam: a granularidade do teste, o tempo que ele necessita para execução, e a dependência que esse teste tem de elementos externos. Então um teste unitário, ele tem a granularidade maior, você tem muito mais código para testar muito menos código, você testa porções menores de código, construindo uma suíte de teste às vezes maior, que vai testar de fato a unidade. Ele deveria demorar cerca de milissegundos a poucos segundos para ser executado, porque como ele é a rede de proteção inicial do seu software, ele deveria ser uma suíte de teste que você deveria conseguir executar com frequência, a cada build, a cada commit, que seja. Então, se um desenvolvedor tiver que executar uma suíte de teste unitária automatizada e ela demorar minutos, às vezes horas, ele vai ser compelido, por definição, a não executar, e isso já, por definição, não fica interessante para que a gente mantenha realmente aquele código sendo evoluído e não quebrado, então deveria executar de milissegundos a poucos segundos. E a dependência de elementos externos, num teste unitário, não deve ocorrer. Então, um teste unitário, ele se utiliza muito de mox, que, por exemplo, você tem uma relação com o banco de dados, você não quer testar se o banco de dados funciona, isso aí a gente espera que já seja verdade então você mocka na sua estrutura de dados, você constrói um cenário conhecido, um elemento entre aspas fake, que se comporta como aquele elemento.

Felipe Chagas: Você vai simular o banco de dados.

Felipão: Exatamente.

Felipe Chagas: Não vai ter um banco de dados ali mesmo não, vai ter só um cara que “olha, estou fingindo que é o banco de dados aqui”.

Felipão: Exatamente, então ele não deve ter dependências externas, que sejam de bancos de dados, que sejam de webservice.

M1: Só um negócio, alguém explica o que é o mocar, porque mocar é um termo bem, vocês conhecem, o que é mocar? Porque ficar mockado é ficar escondido, na gíria. O que é o moc?

Mateus Araújo: Bom acho que moc seria você construir esse cenário que você conhece. Então, basicamente, a estrutura de um teste, independentemente do tipo de ele seria basicamente given, when, then. Dado que uma coisa aconteceu, quando a minha aplicação executar, então eu espero que um resultado chis aconteça. Então o mock seria esse given, seria você construir um cenário, que você tem certeza qual é esse cenário, então, essa certeza de qual é esse cenário, quando você executar o software, vai te dar um outro resultado que você sabe qual é, então você vai conseguir comparar esse resultado que software te deu com o resultado esperado. Então, por exemplo, quando o Chagas cita os exemplos da soma, o mock seria você, num método que faz a soma de dois números, o mock seria o dois e o dois.

Felipão: Alguém que te entregasse aquele parâmetro de entrada.

M1: Fala assim, se isso envolvesse uma complexa consulta no banco, você ia fugir disso para poder testar exatamente aquela situação.

Felipe Chagas: Pegando o exemplo dos dois números, vamos supor que a aplicação soma dois números e depois ela salva esse resultado no banco. E eu estou fazendo um teste unitário só da soma de dois números, eu não quero, nesse momento, testar o comportamento do banco, então eu vou simular que eu salvei no banco, deu sucesso sua operação de salvamento aqui no banco. Mas o teste, ele está focado só na parte da soma dos números, como estava conceituando, isso faz parte do teste unitário, o teste ele envolve outros sistema, ou até partes do mesmo sistema, ele já é uma outra categoria de teste, que são os testes de integração.

Mateus Araújo: Acho que é importante só, para fechar esse assunto do teste unitário, é importante ressaltar que a gente mocka o banco, a gente moca outro serviço, não é porque a gente está querendo mentir não, é porque.

M1: Poder focar.

Mateus Araújo: Exatamente. Porque integração com essas aplicações, tanto em termos computacionais, quanto em termos de tempo, isso é (caro) [00:19:01], então a gente não vai conseguir ter esse teste que o Felipão citou, que vai rodar em milissegundos e até em segundos, se a gente tiver que fazer integração com vários sistemas.

M1: Então só para fazer um resumo, então estava falando o seguinte: um primeiro teste automatizado, vamos dizer, um nível mais próximo do baixo que existe seria cada lógica que eu faço eu testo, isso é o teste unitário, se eu estiver fazendo isso, eu vou estar garantindo que tudo o que eu vá escrever está funcionando corretamente.

Marcos Araújo: Sim.

M1: Só que ainda falta eu garantir que isso funciona corretamente de forma integrada, que aí seriam os testes integrados?

Felipe Alves: E determinística, também. Os testes não podem depender de variáveis aleatórias. Então, vamos supor que eu tenha um sistema que leia um valor da bolsa de valores, de uma ação específica, para depois fazer uma série de ações, eu não vou poder ler o valor do dia naquele momento para um teste unitário, porque eu não sei qual vai ser isso e eu não vou conseguir medir qual que vai ser o resultado posterior a essa leitura. Então os testes unitários têm um caráter determinístico.

Felipão: Idempotente, que a gente chama, que é: se você executar aquele mesmo teste unitário 100 vezes, ele tem que dar o mesmo resultado. Ele não pode se alterar por parâmetros externos. Só me ocorreu aqui, você pediu a conceituação de mock, a gente pode conceituar também de uma forma linguística, porque o mock em inglês é imitar, então, é de fato algo que imita alguma coisa. Tem aquele pássaro, o mocking bird, o tordo, que é um pássaro capaz de ouvir e repetir, e imitar o som, então o mock pode ser conceituado como simplesmente algo imitando outra coisa.

Felipe Chagas: Trazendo para cá, é o papagaio.

Felipão: No Brasil é o famoso papagaio.

Felipe Chagas: O papagaio.

Mateus Araújo: É um nome bom para usar.

Felipão: Dando sequência nos tipos de teste, a gente já falou bastante do teste unitário. Uma outra coisa que o teste unitário ajuda bastante a gente a conseguir é, associado ao TDD, que depois meus colegas podem definir também o que é o TDD, que é o desenvolvimento orientado a teste, o test driven development, ele não suporta uma capacidade de pensar muito bem antes de sair construindo, porque se você orientar toda a sua construção aos testes unitários, principalmente, você vai, inexoravelmente, ter um código mais modularizado, porque você vai começar a pensar: quais são as suas unidades. Então depois você já tem um software mais desacoplado, mais modularizado. Mas então, dando sequência, o teste de integração, o que seria o teste de integração nessas três grandezas que eu comentei. Do ponto de vista do tempo que ele gasta para ser executado, ele já pode gastar alguns segundos a, talvez, poucos ou alguns minutos. É um teste mais indicado para quando você está, de fato, integrando a solução, às vezes você tem um sprint, ele vai fazer a integração de todas as features que foram construídas naquele sprint, é bem interessante que um teste integrado, obviamente, junto com os testes unitários, sejam executados dentro de um “pipeline” de entrega, que a gente vai falar um pouco mais sobre no episódio de DevOps, que é a entrega automatizada. Então os testes de integração são interessantes de serem executados nesse momento. Do ponto de vista de granularidade, ele já é menos granular. A gente testa uma conjunto de unidades funcionando em conjunto. Eu dei o exemplo simples lá da soma, das multiplicações e divisões, nesse momento você já pode integrar essas operações, para se certificar de que uma forma orquestrada, trabalhando de uma forma conjunta, elas continuam funcionando. Porque não é incomum, às vezes a gente testar as unidades, todas elas estão funcionando individualmente, mas na hora em que começa a fazer a junção daquelas funcionalidades alguma coisa não está funcionando, que seja pelo protocolo que elas comunicam, enfim.

Mateus Araújo: Acho que um exemplo bem simples disso aí, Felipão. Seria o seguinte, você tem um sistema que trabalha com medida que trabalha com metros, e você tem um outro sistema que trabalha usando pés. Os testes de integração do sistema que trabalha usando metros todos passam, os testes unitários do sistema que usa pés também passam, mas quando você faz a integração desses sistemas, provavelmente alguma coisa vai falhar.

Felipão: Aí você percebe que faltou uma unidade para converter a unidade de medida.

Mateus Araújo: Aí nesse momento os testes de integração vão poder te mostrar que houve essa falha de comunicação entre sistemas diferentes.

M1: A gente entende porque o cliente reticente, porque realmente tem que gastar dinheiro para fazer teste. Porque você testa o unitário, aí já testa um monte de coisa, ao mesmo tempo na hora de integrar podem surgir várias condições nas quais você não pensou, situações diferentes, você tem que testar também. Tudo isso consome esforço, consome tempo, e o cliente está com pressa. Mas é isso que vai garantir depois a agilidade para atualizar.

Felipe Chagas: E mesmo depois que o sistema já está rodando em produção, uma prática muito interessante, é, assim que (o time) [00:23:52] de sustentação identificar um bug, ele fazer um teste que quebraria, caso esse bug ainda fosse existente no sistema. Então, você pode aplicar o TDD até para [00:24:03] (times) [00:24:03] de sustentação, que aí você está garantindo que ele não vai voltar, “nossa, de novo esse problema”.

Felipão: Tipo uma vacina, você usa um pedacinho do vírus morto para poder construir a vacina.

Felipe Chagas: Exatamente.

M1: Agora, tem teste de UI, que você estava falando também.

Felipão: É, a última grandeza que eu estava falando e não cheguei a comentar só, do teste de integração, é que o teste de integração já pode ter uma dependência de elementos externos. Então, em um teste de integração você já pode compor um chamado a uma base de dados, um chamado a uma webservice, porque realmente você quer construir algo que faça a validação daquilo funcionando junto. E, por último, o teste de UI, que é um teste que vai fazer a automatização da utilização do sistema, ou de uma determinada feature já pronta. O teste de UI vai mockar o ser humano, ele vai imitar o comportamento do ser humano, já em uma tela, preenchendo um campo, clicando em um botão. Aí você consegue automatizar um teste sem a necessidade de juntar um time para ficar utilizando o sistema e testando alguns fluxos básicos e até mais complexos. Aí a granularidade dele já é menor ainda, você teste que vão compreender centenas, milhares, dezenas de milhares de linhas de código, e ele também deve ter uma dependência com outros serviços, a exemplo do teste de integração, e já é um teste que pode demorar às vezes até horas, se você estiver testando toda uma aplicação, ele pode demorar minutos, até horas para ser executado. Então, compondo esses três tipos de teste, um time que estiver construindo bons testes unitários, testes de integração, eventualmente um teste UI, eu acho que está bem seguro para evoluir, para se considerar agilista na evolução do software.

M1: Eu queria fazer uma pergunta, que é assim, beleza, você tem os três tipos de teste. Como é que eu gerencio isso, eu sei que existe uma coisa chamada cobertura de teste, eu devo ter 100 por cento de cobertura, vamos primeiro definir o que é cobertura, e como é que vocês definem a quantidade de teste que vai ser vai feita, já que o esforço é grande. Ou se a prática é fazer 100 por cento, mesmo, e garantir que está tudo coberto.

Mateus Araújo: Eu vou só voltar um pouquinho aí (José) [00:26:20], desculpa aí, mas é porque, como eu falei que a definição de teste é uma definição para a qual não existe um consenso, eu vou discordar um pouquinho só do Felipão. Que eu vou colocar um quarto tipo de teste, que seriam os testes de carga e os testes de segurança, que basicamente é você avaliar como que a sua aplicação se comporta à medida que a carga, a quantidade de uso dela aumenta, ou à medida que usuários tentam burlar a sua aplicação, que também são testes que são importantes de serem feitos.

Felipão: Testes automatizados de segurança e carga, você está certíssimo.

M1: E cada vez mais importantes.

Felipão: Não discordamos, concordamos.

Mateus Araújo: Que bom.

Felipe Chagas: E isso responde àquela pergunta, se o sistema vai aguentar quando entrar em produção, só tem um jeito de saber, com um teste de carga. E tem outros tipos, teste de estresse, enfim, aí é um universo à parte. Mas respondendo à pergunta sobre cobertura de teste, o que é? É uma métrica, bem simples, ela mede a porcentagem do seu código que tem um teste executando aquele trecho. Então, se eu tenho um teste que literalmente passe, (raminhe) [00:27:23] pelo código que está sendo testado, ele marca, então: essas linhas de código estão testadas, essas outras são as linhas não testadas, e disso consegue-se fazer uma porcentagem com a relação entre as linhas de código que são testadas e as que não são. Ela é uma métrica muito importante, mas não necessariamente ela vai garantir a qualidade dos testes, porque eu posso fazer um teste que não valide nada, mas que passe por todas as linhas de código, então a cobertura de código, a gente diz, é o primeiro indicador, mas não pode ser o único. A gente vai ter que uma avaliação subjetiva na qualidade desses teste. O teste também vai passar pelo mesmo processo que o código passa de garantia de qualidade, de (cool request) [00:28:04], de validação em dupla, tem que saber se esses testes de fato.

M1: Alguém deveria revisar também os teste, os cenários, et cetera.

Felipe Chagas: Exatamente, os teste deveriam ser feitos por mais de uma pessoa, para a gente poder pegar possíveis falhas que estejam sendo feitas ali nos testes. Porque pior do que não ter teste, é ter teste mal feito, porque, uma coisa que os testes automatizados vêm para trazer é a confiança, confiança é uma palavra chave nesse cenário. Então, eu tenho confiança que o meu sistema está funcionando, então eu posso ter coragem de fazer alterações, sem testar o sistema todo, porque meus testes estão dando a confiança de que ele vai responder bem. E se eu tenho testes mal feitos, mesmo que a cobertura seja alta, eu tenho uma falsa confiança, então é bem verdade isso, é melhor não ter teste, do que ter teste mal feito.

M1: Entendi

Mateus Araújo: É se você pensar o código como um texto, a cobertura seria o quanto desse texto foi lido, mas não adianta ler um texto sem entender o que está acontecendo.

M1: Boa analogia. A gente fez um podcast sobre pensamento sistêmico, aquele o de rule beating, quebrar as regras, a coisa mais fácil que tem é um cara dar uma olhada e ver que a cobertura está ruim, inventa um teste qualquer ali só testa um cenário muito bobo e fala: beleza, cobri ali, vamos em frente. E na verdade ele teria que exaurir os cenário ali. Mas assim, existe algum tipo de recomendação, tudo bem que não é só a cobertura, mas pensando na cobertura, é 100 por cento, em um software novo tem que ter 100 por cento, ou 100 por cento é bobeira?

Felipe Chagas: Depende da tecnologia e da linguagem. Tem algumas linguagens que têm códigos gerados, e não necessariamente precisa ter 100 por cento, porque esses códigos são gerados automaticamente pela sua IDE, você não precisa gastar esforço para gerar teste nessa parte do código, então você vai ter algo em torno de 90 por cento, 80 por cento, dependendo se tem muito desse cenário, mas existem outros que o 100 por cento não é impossível não. Mas o objetivo talvez não seja mirar no 100 por cento, mas mirar em ter um sistema com confiança, e provavelmente ter uma alta cobertura, então acima de 90 por cento, é difícil falar um número, porque isso vai depender muito da tecnologia, da linguagem e do próprio sistema.

Felipão: Eu acho que é caso a caso, eu sempre sou muito categórico com os times, eu acho que o time tem que ter um conhecimento muito bom daquele software que está sendo construído. Então, eu acho que se o time falar assim: minha cobertura está em 50 por cento, não parece que é uma quantidade suficiente, mas se eu perguntar por que está em 50 por cento e o time me falar: porque a gente avaliou o código e entendemos que nessa porção do código um teste unitário não vai se pagar, ou nessa outra parte é código gerado, então foi decidido.

M1: Foi decidido.

Felipão: Isso, não foi por falta de priorização, não foi por falta de enxergar valor, mas foi porque eles compreendem tão bem o cenário que têm nas mãos que decidiram que 50 por cento para eles é o que vai trazer a confiança de que o Chagas falou. Então, a chance de eles estarem certos é razoável, foi deliberado e não foi, enfim.

Felipe Chagas: Outra coisa que é comum também é você garantir alta cobertura de teste nas partes que têm regra de negócio. Então, tem outras partes do código que vão ser comportamentos funcionais, et cetera. Mas a prioridade, a parte de negócio está 100 por cento, funcional está uns 20, porque, igual o Felipão falou, a gente entende que o valor está no módulo do negócio.

M1: Só para ficar claro, qual a diferença no que vocês está dando para funcional e regra de negócio?

Felipe Chagas: Então, o funcional, no caso, seriam coisas da tecnologia mesmo, vamos supor tem uma PI, e essa PI é autenticada, então tem uma segurança, usuário e senha, e todo um arcabouço por trás para garantir que tenha uma criptografia, et cetera. A regra de negócio seria validar usuário e senha, porque a regra foi definida e, por exemplo, pode ter uma regra que se o cara digitar três vezes a senha errada, ele tem que ser barrado, isso que seria a regra de negócio. Agora, qual que é o tipo de criptografia que o (inint) [00:32:44] traz.

M1: Você não precisa testar que está criptografado, por exemplo. Porque isso é dado pelo componente que você está usando, ou pelo.

Felipe Chagas: Se você tem tempo, é bom. Mas, em questão de priorização, testar a regra de negócio, nesse cenário, faz mais sentido.

Mateus Araújo: Se tivesse um índice de cobertura da regra de negócio, seria muito bom. Porque a gente levantava esse índice e pronto, era mais fácil de se medir o avanço.

Felipe Chagas: Se você tem um sistema até modularizado em camadas bem desacopladas, até consegue fazer isso, tem um projeto que a gente conseguiu definir qual que era a porcentagem da regra de negócio e a porcentagem do sistema como um todo, e (embocanhamos) [00:33:14] isso.

M1: Interessante, ficou um índice cobertura melhor, vamos dizer assim.

Felipe Chagas: Teve mais visibilidade dele.

M1: Agora, a interface com o usuário é difícil para caramba de testar, não é?

Mateus Araújo: Bem difícil, porque geralmente a interface é muito dinâmica, então, mexer na interface implica em mexer no teste. Muitas vezes esse teste de interface a gente deixa para ser feito por um humano. Até porque, você tem interface que vai acessar uma tela no computador, essa tela vai disparar o envio de um e-mail, ou de um SMS para ele, e você precisa testar isso, então testar isso de maneira automática é bem difícil, e é bem caro também.

Felipão: Não que não dê para ser feito.

M1: E na minha ignorância, tem um tanto de browser, aí tem que acontecer uma coisa, em um acontece, no outro não acontece, dá para automatizar isso, ou não?

Felipe Chagas: Dá. Existem ferramentas que conseguem simular o comportamento de diferentes browsers, inclusive você consegue paralelizar, ao mesmo tempo que está testando em um Firefox, está testando em um Chrome, está testando em um Internet Explorer, ou Edge. Para teste de (wiz) [00:34:22], existem muitas ferramentas hoje em dia, algumas pagas, outras open source, gratuitas, para poder realizar esse tipo de teste, eles são mais custosos de serem feitos, de serem programados, muitos deles são baseados até em gravação, do tipo: eu vou me comportar aqui como se fosse o usuário, ele está gravando meu clicks e qual botão eu estou fazendo, e depois eu vou repetir isso, e diversas vezes conseguir ver o resultado final. Mas é possível simular sim o comportamento de vários browsers.

Felipão: Isso é muito utilizado até no universo mobile, que a gente tem uma infinidade de hardwares diferentes.

Felipe Chagas: É, o Android é muito fragmentado.

Felipão: O Android é muito fragmentado, então é uma ferramenta interessante para a gente conseguir perceber o funcionamento daquela aplicação, pelo menos nas versões mais utilizadas, estatisticamente falando, para a gente saber qual vai ser o comportamento do software no pareto dos usuários.

Felipe Chagas: Para evitar o famoso “na minha máquina funciona”, testei na minha máquina, mas testei, ao mesmo tempo, em 200 outras máquinas também.

M1: Então, gente, a gente está caminhando para o final do programa, deixamos de alguma coisa, fizemos uma cobertura boa sobre os testes automatizados?

Felipão: O podcast está cobrindo bem o assunto?

M1: Falamos da importância, falamos dos tipos, falamos, mais ou menos sobre como gerir a questão de cobertura, tem algum outro aspecto que a gente pode estar esquecendo?

Felipão: Eu gostaria, até na parte mais filosófica da coisa do que na parte técnica, de dizer para os nossos ouvintes que às vezes ficam pensando no retorno de construir o teste automatizado. Eu acho que uma forma legal de se avaliar, se você fica reticente de pagar pelo teste automatizado, porque você acredita que o que vai te dar o retorno é a geração de valor, e se a gente for utilizar os conceitos agilistas para ser o drive da geração de valor, para a gente ter bastante correção de valor, bastante adaptação, correção de curso, testar hipóteses, OKS, que é tudo aquilo o que a gente já falou em outros episódios. Quanto mais rápido a gente testar uma hipótese e falhar ou suceder nela, mais rápido a gente vai aprender sobre como aquele software vai se comportar neste mundo (vuca) [00:36:41] que a gente está lançando ele. Então, se a gente está dizendo que o teste automatizado é aquela rede de proteção, é o escudo do Trezentos de esparta, igual você já usou essa metáfora. Se a gente acredita que ele traz essa proteção, traz essa segurança, a gente cria mais coragem para testar mais hipóteses em menos tempo. Então a gente tem coragem de fazer mais publicações daquela aplicação. Se a gente pegar exemplos grandes: Facebook, Instagram, o próprio Google, eles executam dezenas, centenas, milhares de deploys por dia, por semana, como que eles teriam coragem de fazer alterações com tanta frequência se eles não tivessem a segurança de, às vezes uma feature, pontual que eles alteraram, quebrou todo o sistema. Então, é muito importante a gente entender que os testes automatizados se pagam também por isso, você vai ter mais coragem para testar mais hipóteses, e se você vai testar mais hipóteses, você vai entender mais sobre como o software está alterando o seu negócio, e a chance de você estar gerando mais valor com mais frequência é aumentada também.

M1: Perfeito.

Mateus Araújo: Um último ponto aí, que a gente acha, às vezes, que teste é uma coisa nova, mas na verdade a primeira vez que surgiu o termo na engenharia de software foi em 76, então já algum tempo em que estamos falando sobre isso.

M1: Nós estamos caminhando para fechar, e apesar de a gente ter feito todo esse drama de tentar convencer que tem que usar, eu acredito que nós estamos numa era na qual isso vai ficar totalmente para trás, na medida em que os negócios ficam digitais, igual aos clientes que já estão sendo, de certa forma, obrigados a adotar a cultura (ágil) [00:38:25] por uma questão quase de sobrevivência, quem tem um negócio apoiado em uma plataforma digital, obviamente tem que poder mudar ela continuamente, e esse é um dos aspectos fundamentais. Então, eu acredito que isso vai ser uma questão completamente superada, mas que é importante explicitar, porque tem gente que veio de uma era na qual o software era acessório. Eu sempre falo isso aqui no podcast, então, é claro, se você faz o sistema uma vez na vida, e pretende mexer pouco nele, alguém poderia realmente falar, seria bastante discutível se você deveria investir em teste, “ah, não vou mexer no sistema nunca, se der um problema um dia, eu dou um jeito de resolver”. Agora, não, eu vou fazer um sistema sobre o qual o meu negócio está apoiado, eu vou trabalhar em mexer nele o tempo todo, e preciso fazer isso rápido, um dos aspectos são os testes automatizados, os outros nós vamos ver no episódio de Devops, e, na verdade, a gente pode fazer um episódio sobre uma arquitetura limpa, também, porque é claro que para mexer rápido, não é só testar rápido e colocar rápido em produção, tem que ter sido bem feito também. Isso aí, então, pessoal, vamos terminando o episódio aqui, despeçam-se.

Felipe Chagas: Abraço aí, galera.

Mateus Araújo: Pessoal, bom dia.

Felipão: Valeu, pessoal, até a próxima.