Teste de unidade em código ou sistema legado

Teste de Unidade: Por que não da certo no meu sistema?

Olá! Neste artigo eu explico um pouco sobre a minha experiência com a dificuldade de implementar testes de unidade em um sistema com mais de 10 anos de existência. Neste artigo você poderá conferir as melhores práticas que pude aprender na vivência do dia a dia que curso nenhum irá lhe ensinar. Se você está sofrendo para implementar um teste de unidade leia este artigo, tenho certeza que irá lhe ajudar!

Eu preferi não aprofundar ao nível técnico, já que, a parte de “como se cria um teste de unidade” você encontra com facilidade em cursos ou livros.

Sumário

  1. Uau! Quero criar um teste de unidade!
  2. O que é um teste de unidade?
  3. Antes de prosseguir, já ouviu falar em TDD?
    1. Qual a vantagem de usar o TDD?
  4. Por que implementar teste de unidade não da certo no meu sistema?
  5. SOLID, muito SOLID!
    1. Princípio da Responsabilidade Única (SRP)
      1. Como aplicar o Princípio da Responsabilidade Única (SRP) e como ele me ajuda?
    2. Princípio do Aberto Fechado (OCP)
    3. E quanto aos outros princípios SOLID?
  6. Criar testes deve ser parte do processo de desenvolvimento!
    1. Criando o teste de unidade antes de criar a funcionalidade (TDD)
    2. Criando o teste de unidade durante o desenvolvimento de uma funcionalidade
    3. Criando o teste de unidade somente depois que terminou de criar a funcionalidade completa
  7. A dificuldade de tentar criar testes de unidade para código legado (antigo)
    1. Devo tentar criar testes unidade para código legado?
    2. Quero criar testes para meu código legado, como fazer?
    3. Nem sempre você conseguirá criar testes no processo de desenvolvimento
  8. Cuidado com os testes que quebram à toa!
    1. O que fazer para que meus testes não quebrem sem um bom motivo?
  9. Criar testes de unidade é uma cultura, não uma ferramenta!
  10. Meus colegas não querem criar testes de unidade, e agora?
  11. Utilize Código Limpo e SOLID nos testes de unidade também!
  12. Conclusão

Uau! Quero criar um teste de unidade!

Então você decidiu comprar um livro de testes de unidade, ou quem sabe, comprar um cursos sobre testes de unidade e chegou a hora de usar seus conhecimentos no projeto que você dá manutenção. Notou alguma dificuldade? Pois é, a vida real é bem diferente dos livros e dos cursos. Isso ocorre porque os exemplos propostos nos livros e cursos são realmente muito simples.

Não me entenda mal, não estou dizendo que livros e cursos sobre testes de unidade são ruins, nada disso! Muitos deles oferecem um bom conhecimento introdutório sobre o assunto. Antes de eu ter conseguido algum sucesso em implementar testes de unidade no dia a dia, tive que estudar bastante, li alguns livros e fiz alguns cursos sobre o assunto. E claro, foi necessário muita insistência em tentar diversas vezes até ficar proficiente.

Creio que a grande questão que faz você falhar é que, os livros e os cursos não focam em ensinara criar testes tendo como base códigos legados. E convenhamos, códigos legados (velhos e confusos) são bem difíceis de lidar em algumas situações. Refatorar código assim é uma tarefa árdua e normalmente exige reescrita.

O que é um teste de unidade?

Antes de prosseguir, é importante definir de forma clara o que é um teste de unidade. Em suma, é um código muito específico que exercita algum trecho muito específico do seu código fonte de produção. Ou seja, é um código que chama um determinado método de alguma classe específica passando os parâmetros solicitando e validando o retorno ou o comportamento após a execução.

É importante ficar atento à isso porque é muito fácil confundir tais testes com testes de integração por exemplo. Testes de integração são bem maiores e complicados de se criar.

Antes de prosseguir, já ouviu falar em TDD?

O TDD (Test Driven Development) é uma técnica de desenvolvimento que visa criar os testes de unidade antes de criar a funcionalidade propriamente dita. Parece complicado né? No começo é um tanto difícil de entender e até mesmo aceitar isso. Depois que você aprende, entende e começa a usar, você não acredita no quão fácil fica para criar seus testes.

Qual a vantagem de usar o TDD?

A grande vantagem de se usar o TDD no desenvolvimento da sua funcionalidade é o design final do seu código. Sim, a estrutura será totalmente diferente se você utilizar o TDD.

Se você se empenhar em criar os seus testes usando a esta técnica, você terá um código fonte altamente testável, pois, você foi obrigado a criar o seu código fonte de acordo com as exigências dos testes. É bem difícil criar um código ruim se você usar o TDD na implementação de testes realmente de unidade.

É um pouco difícil de fazer com que você compreenda isso apenas lhe explicado aqui. Isto é algo que você verá na prática. Eu garanto que, se você se empenhar nisso, você terá sucesso!

Por que implementar teste de unidade não da certo no meu sistema?

É difícil afirmar com certeza os motivos pelo qual você está enfrentando problemas. Mas, eu garanto que provavelmente está diretamente relacionado à qualidade do código a ser testado! Códigos ruins não são testáveis, e se você insistir, terá mais problemas do que soluções no futuro. Ou seja, algo que deveria lhe ajudar no problema, te dará terríveis pesadelos!

É praticamente impossível falar em teste de unidade sem falar em Código Limpo! Se você ainda não ouviu falar em Código Limpo, faça uma rápida pesquisa e obtenha algum conhecimento a respeito. Logo abaixo eu abordo um pouco sobre SOLID. Isso lhe trará algumas ideias do que é Código Limpo.

Quanto mais limpo for o seu código, mais fácil será criar testes pra ele. Isso é muito evidente quando você respeita as premissas do código limpo, criando classes e métodos pequenos, e que tenham uma única responsabilidade. Alias, o princípio da Responsabilidade Única é crucial para que você tenha sucesso em criar seus testes.

SOLID, muito SOLID!

Algo que pode lhe ajudar muito, muito mesmo, nessa jornada são os princípios SOLID. Se você conseguir os princípios SOLID no desenvolvimento das suas funcionalidades, você terá um código altamente testável, sério! Vamos ver a seguir cada um dos princípios e como cada um deles te ajuda.

Se você quer criar testes de forma simples e sem complexidade de uma forma muito natural, siga os princípios SOLID, vão lhe ajudar muito.

Princípio da Responsabilidade Única (SRP)

Este princípio nos diz que, uma classe ou método deve ter uma única responsabilidade. Quer um exemplo? Digamos que você esteja criando a funcionalidade de envio de e-mail. Você codifica tudo numa classe só? Ou cria diversas classes? Vamos aprofundar um pouco nesse exemplo?

Vamos tentar sem usar o SRP: Você cria uma única classe “EnviadorDeEmails”, e nesta classe, você cria o método “Enviar(parâmetros)”. Neste exemplo, o método “Enviar” faz tudo: Define o assunto, corpo, anexos, outros detalhes e envia o e-mail (conexão SMTP). É absolutamente impossível criar algum teste de unidade que nos ajude com esta estrutura! Pense em como você criaria um teste que valide o corpo do e-mail? E como você validaria se o assunto está correto? O seu teste iria realmente enviar um e-mail? Difícil né?

Como aplicar o Princípio da Responsabilidade Única (SRP) e como ele me ajuda?

Simples, vamos exemplificar o uso do SRP. Vou definir uma estrutura hipotética de uma funcionalidade de envio de e-mails, ok? Vamos lá:

Para começar, devemos criar uma classe que saiba montar o corpo do e-mail. Então, criaríamos a classe “MontadorDoCorpoDoEmail” com um método chamado “Montar(parâmetros)” que nos devolve o corpo do e-mail já pronto para ser enviado. Note o quão mais fácil ficou para criar um teste que valide se o corpo do e-mail foi gerado corretamente. Sem o SRP seria impossível, com o SRP basta instanciar a classe, chamar o método passando os parâmetros exigidos e então, validar o retorno!

No mesmo sentido da classe “MontadorDoCorpoDoEmail”, nós poderíamos criar a classe uma classe que sabe somente como enviar o e-mail. Esta classe seria a responsável por estabelecer uma conexão SMTP e enviar de fato o e-mail. Digamos que o nome dela seria “EnviadorDeEmails” que teria um único método público chamado “Enviar(parâmetros)“. Este tipo de classe, que estabelece conexões com o mundo externo, é um pouco mais difícil de ser testada de forma unitária. Entretanto, não é impossível!

Criar testes é muito mais fácil quando você respeita de fato o princípio da responsabilidade única, pois, você terá classes e métodos menores, que tem somente uma única utilidade. Muito diferente de classes gigantes com métodos enormes que tentam resolver tudo num só lugar (impossível de testar). Fique atento à isto, vale o esforço!

Princípio do Aberto Fechado (OCP)

Este princípio, se aplicado, torna os testes de unidade estáveis. Por quê? Porque o código escrito seguindo este princípio fica aberto para ser estendido (herança, interfaces, etc) e fechado para alterações. Em outras palavras, código escrito e que funciona, não deve sofrer alterações futuras pois, ele tem somente uma única responsabilidade e ele resolve somente um problema muito específico. Se um determinado método precisa ser alterado, é porque a regra de negócio mudou, ou então, você não está aplicando de forma correta estes princípios.

Quer um exemplo prático? Digamos que nós temos uma classeSomar” e dentro dela temos o método “Soma(números)”. Qual seria a necessidade desta classes ou o método dela sofrer alguma alteração? Não faz muito sentido né? Neste exemplo, teríamos vários testes de unidade que seriam um tanto sólidos e que garantem o funcionamento da classe “Somar”. Isto torna a classe “Somar” uma caixinha fechada, que pode ser estendida e utilizada em outros pontos, mas nunca alterada. Isto torna o seu código altamente confiável.

Se você criar suas classes e métodos juntamente com seus testes utilizando o OCP, você não terá dores de cabeça futuras com alterações de códigos. Pois, o código não precisará ser alterado. E, se o código não sofrer alterações, nunca quebrará visto que, seu comportamento nunca será alterado.

E quanto aos outros princípios SOLID?

Eles também são importantes, porém, são mais difíceis de entender e de explicar de forma teórica. Resumidamente, podemos entender os demais princípios assim:

  • Princípio da Substituição de Liskov (LSP): Tenha cuidado ao utilizar heranças! Se você utilizar desenfreadamente, a estrutura final pode ficar um tanto complexa. Sempre que possível, evite! Isto trará mais clareza ao seu código facilitando criar testes;
  • Princípio da Segregação de Interfaces (ISP): Crie seus módulos de forma que eles fiquem enxutos. Módulos com interfaces que tenham muitas responsabilidades tendem a se espalhar muito facilmente pelo sistema. Isto eleva muito o acoplamento e dificulta  muito evoluções futuras. Basta seguir o Princípio da Responsabilidade Única e o Princípio do Aberto Fechado e você não terá problemas com o ISP.
  • Princípio da Inversão de Dependência (DIP): Se aplicado, isto torna o seu código menos acoplado, visto que, classes e métodos receberão as ferramentas que precisam para funcionar, ao invés de instanciá-las por si só. Isto trará muita facilidade na criação dos testes de unidade.

Se você quiser saber um pouco mais sobre SOLID, dê uma olhada no artigo da Caelum: http://blog.caelum.com.br/principios-do-codigo-solido-na-orientacao-a-objetos/.

Criar testes deve ser parte do processo de desenvolvimento!

Em que ponto do processo de desenvolvimento você quer criar seus testes de unidade? Antes, durante ou depois de criar a funcionalidade?  Tentar separar o processo de desenvolvimento do processo de criação dos testes é uma péssima ideia. A criação dos testes deve ser feita antes ou durante a codificação da solução, nunca depois.

Curioso para saber o resultado em cada uma das opções? Vamos lá!

Criando o teste de unidade antes de criar a funcionalidade (TDD)

Este sem dúvida é o melhor dos cenários! Você terá como resultado um código totalmente testado com uma alta cobertura (code coverage) de testes. Você de fato programará guiado por testes, onde você cria o teste, e então, implementa o que será testado.

Na prática, seria assim: Cria o teste -> Cria a funcionalidade, cria o teste de unidade -> cria a funcionalidade, e assim por diante

Criando o teste de unidade durante o desenvolvimento de uma funcionalidade

Este cenário está entre usar o TDD e o cenário onde você cria o teste de unidade somente no final. Você terá bons resultados se você for criando o teste de unidade conforme cria a  funcionalidade.  Neste cenário você ainda terá um bom código, visto que, sempre que criar um teste de unidade para um método recém criado, você terá o feedback imediato sabendo se a qualidade do método é boa ou ruim.

Na prática, seria assim: Cria a funcionalidade -> cria o teste, cria a funcionalidade -> cria o teste, e assim por diante

Criando o teste de unidade somente depois que terminou de criar a funcionalidade completa

Este é o pior dos cenários, onde você provavelmente irá ficar frustrado. É totalmente indesejável tentar criar os testes somente depois que terminou de criar toda a funcionalidade. Isso acontece porque você perceberá que seu código não tem uma boa estrutura, e gastará muito tempo tentando refatorar (ou reescrever) o código para aumentar a qualidade tornando-o testável.

Outro ponto muito negativo de deixar para o final é que, durante o desenvolvimento da solução, você provavelmente testará manualmente o que está implementando. Isso gasta muito, muito tempo! Na minha experiência, quando eu crio uma funcionalidade utilizando testes de unidade antes ou durante o desenvolvimento, quando vou testar “na vida real”, quase sempre funciona perfeitamente. É incrível!

Mais um ponto negativo é que, se você deixar a criação dos testes para o final, será bem possível que seus “superiores” eliminem esta fase por “tomar tempo”, uma vez que, em teoria, a funcionalidade já está pronta não é mesmo? A questão é que, pronto é muito diferente de funcional. E principalmente, qual a confiabilidade do código que foi escrito sem testes? Não permita que isto aconteça, sério!

Na prática, seria mais ou menos assim: Cria funcionalidade, cria funcionalidade, cria funcionalidade -> Tenta criar os testes de unidade -> Frustração.

A dificuldade de tentar criar testes de unidade para código legado (antigo)

Se você é um desenvolvedor que lida com um sistema que já tem alguns anos de experiência (existência) e que, possui uma base de código “ruim” e não testável, você está no lugar certo!

Se você está tentando criar testes para funcionalidades que estão sendo criadas, é porque não tentou criar testes para código legado. Sabe aquele método que todos tem medo de mexer, que tem mais de 1.000 linhas, que faz inúmeras ações e tem várias responsabilidades? Então, como você faria para criar um teste de unidade pra isso? É realmente impossível sem que você tenha que reescrever o código em questão.

Devo tentar criar testes de unidade para código legado?

Eu diria que… não! Não é uma boa ideia. Provavelmente você não conseguirá bons resultados tentando criar testes de unidade para código legado que não esteja bem estruturado. Para que você consiga criar testes para um código ruim, você terá que reescrever ele. Isso tem muitas chances de virar uma bola de neve, porque, ao reescrever um trecho (que é acoplado à outros pontos do código), você provavelmente terá que reescrever os demais pontos em também. E assim começa uma trabalho fadado a ser frustrante no final, pois, você gastará um tempo enorme, e não terá bons resultados.

Já tentei algumas vezes, no entusiasmo de tornar certo trecho de código melhor e mais confiável, e as vezes acabava que eu produzia um bug ao tentar evitar bugs. O nome disso é excesso de esmero!

Se o sistema que você dá manutenção tem muitos anos de vida, provavelmente ele tem muitos trechos de códigos que são utilizados todos os dias pelos usuários. Tais trechos de código, por conta do uso corriqueiro, já é suficientemente confiável. Não queria mexer no que já funciona!

Quero criar testes para meu código legado, como fazer?

Se você está ciente dos riscos e do tempo que levará para você ter bons resultados em tentar criar testes para um código legado que é mal estruturado e cheio de acoplamentos, vou te dar alguns conselhos!

É muito comum em sistemas grandes, ao implementar novas funcionalidades, que você tenha que acoplar esta nova funcionalidade à alguma funcionalidade já existente, não é mesmo? É nestes casos que surgem os maiores dilemas! Pois, na ânsia de criar testes para o código que você está criando, você se depara com o código antigo (ruim e não testável) e se vê obrigado à reescrever partes do sistema que não estavam inicialmente no seu escopo.

A principal dica que eu lhe dou nesses casos é: Não tente ferver o oceano! Ferva uma poça por vez! Como assim, Jonatan? Simples: Teste o que for possível de ser testado. Se você está criando algo novo, crie este “algo novo” da melhor forma possível e crie os devidos testes. Se você fizer um bom trabalho ao escrever a funcionalidade utilizando os princípios do código limpo, você conseguirá acoplar esta nova funcionalidade em funcionalidades antigas sem ter que reescrever o código antigo.

Nem sempre você conseguirá criar testes no processo de desenvolvimento

Calma! Não fique frustrado se você não conseguir criar testes sempre que quiser. Lidar com código legado que tenha uma má estrutura é algo muito complicado quando você quer praticar “Código Limpo” e “SOLID”.

Não se prenda à ideia de ter 100% de cobertura de testes no seu código, isso não é possível em sistemas mais antigos (até em sistemas novos isto é questionável). Você deverá focar em criar testes de unidade em funcionalidades que são realmente importantes, pois, lidando com estruturas ruins, isso lhe custará mais tempo. Assim, se a funcionalidade for realmente importante, valerá a pena investir o tempo extra necessário para implementar os testes.

Lembre-se que, mais importante do que sair reescrevendo o código antigo, é estancar o sangramento. Ou seja, parar de criar código ruim e não testável e passar a criar um código lindo, que lhe dê orgulho e abrilhante aos olhos de quem vê! É muito top!!!

Criar testes de unidade é algo que se espalha bem lentamente em sistemas antigos, é um trabalho vagaroso, que lhe dará bons frutos de uma forma lenta, porém, contínua. Vale muito o esforço, não desista nas primeiras e segundas dificuldades! Em pouco tempo você começará a ver os resultados de começar a criar testes, principalmente quando você mexer em algo e o teste acusar que você quebrou algo. Não é maravilhoso isso? O fato do teste achar o bug antes mesmo do usuário ter a chance de xingar você ou seu sistema?

Cuidado com os testes que quebram à toa!

Você está enfrentando problemas com testes “de unidade” que quebram sem um bom motivo? Estes testes por um acaso possuem ligação com o mundo externo? Isto é, com algum WebService, API, SMTP, quem sabe um Banco de Dados? Se sim, o nome disso é teste de integração! Testes de integração não devem compor a base de testes que deve rodar rapidamente no ambiente de desenvolvimento do programador!

Testes de integração normalmente são mais lentos. Se você tiver uma base de testes de digamos… uns 10.000 testes, você precisará que eles sejam muito, muito rápidos para serem executados. Do contrário, ninguém os executarão, pois tomarão muito tempo. Li em algum momento dos meus estudos que um dos quesitos para que um teste seja considerado “de unidade” é que ele leve menos de 100 milissegundos (100ms) para ser executado. Se for maior que isso, com certeza há algo errado.

O que fazer para que meus testes não quebrem sem um bom motivo?

Para que seu teste seja realmente de unidade e útil para você e seus colegas, ele não pode ter contato com o mundo exterior. Ele não pode consumir um WebService que por ventura pode estar fora do ar durante uma execução. Não pode depender de dados armazenados num banco de dados que pode facilmente ser bagunçado por qualquer pessoa. Não pode depender de compartilhamentos de redes que podem simplesmente deixar de existir. Nem nada do tipo! Teste unitário tem que ter contato única e exclusivamente com o código que ele está testando. E este código também não deve ter nenhuma conexão “de unidade” que possa fazer com que ele quebre sem um bom motivo.

Atualmente, no sistema que eu ajudo a dar manutenção, temos vários testes que criamos na época de aprendizado que estão acoplado a: Compartilhamento de rede; API do Google; Banco de Dados (torna o teste lento e instável); WebServices, etc. Estes testes atualmente dão mais trabalho do que solução. Não é incomum um teste assim quebrar e dar trabalho sem motivo nenhum. É necessário ficar muito atento à isto, pois, testes tem que nos ajudar e não atrapalhar.

Leve este ensinamento com você: Os testes só devem quebrar quando há realmente algo de errado! Do contrário, você e seus colegas perderão a confiança nos testes, já que, virou rotina os testes quebrarem e “estar tudo bem, é normal!”. Isso é muito errado! Busque eliminar testes ruins da sua base de testes!

Criar testes de unidade é uma cultura, não uma ferramenta!

Se você leu este super artigo até aqui, você já deve ter percebido que escrever testes vai muito além de utilizar uma ferramenta, não é mesmo? Criar testes requer muita disciplina, requer uma mudança cultural na forma de escrever o seu código fonte. Sem isso, é muito difícil lidar com testes, pois, a dificuldade de implementação se tornará um martírio.

Os testes precisam ser algo bom na sua vida e na vida dos seus colegas. Testes são os guardiões do sistema, eles é que garantem que nada foi quebrado durante modificações naturais!

Outro ponto muito positivo dos testes é que eles de dão coragem e segurança! Como? Simples: Se eu tenho ciência de que o código que vou alterar é testado, eu faço sem medo. Até porque, se eu quebrar algo, os testes acusarão na hora, é incrível! Quando você já tiver uma boa bateria de testes você vai entender o que estou dizendo.

Tomando como princípio que testar requer mudanças às vezes radicais na forma como o código é escrito, pode ser que seja um pouco difícil de fazer com que todos entendam a importância dessa maravilhosa ideia.

Meus colegas não querem criar testes de unidade, e agora?

Este cenário é mais comum do que se imagina. Você, como um bom programador, descobriu os testes de unidade, estudou, vê a importância e agora quer implementar no projeto que você ajuda a dar manutenção. Porém, seus colegas, que ainda fazem códigos “ruins”, sem padrões, sem as premissas do SOLID e Código Limpo, não querem nem saber disso. Pra eles, criar testes vai atrasar o projeto. Pra eles, é perca de tempo. Já passou ou está passando por isso? Sabia que, nem tudo está perdido!

No início, quando descobrimos o que eram os tais testes na empresa onde eu trabalho, também demoramos muito pra perceber que aquilo era o ideal pra nós. Nós que lidávamos com vários bugs toda semana. Nós que, tínhamos medo de mexer em partes do sistema. Depois de certo tempo, aceitamos que era o que precisávamos, então, passamos a usar com mais afinco. Atualmente, temos módulos inteiros cobertos por testes, onde qualquer um pode mexer sem medo algum.

Eu tenho pra mim que, boas culturas são aderidas naturalmente, sem esforço. Tudo o que você precisa fazer é começar! Comece você a escrever testes, não espere pela boa vontade dos seus colegas. Não há maneira melhor de perceber a importância dos testes se não na prática. Sério, vá criando os testes, comece mudando a forma como você escreve seu código, pouco a pouco, um ou outro colega vai perceber e seus olhos vão brilhar com o que você está criando.

Tenho certeza que, se você persistir nessa ideia, seus colegas vão querer mudar também! E se você conseguir fazer com que alguns colegas entendam e preguem a palavra dos testes, a pressão sobre os demais aumentará, fazendo com que eles também adotem tal prática. Alias, leve consigo essa técnica! Vale para qualquer artefato que você queira implantar no time que você faz parte!

Utilize Código Limpo e SOLID nos testes de unidade também!

Muita atenção neste ponto! Seu código de teste também precisa de carinho e atenção! As mesmas boas práticas que você passará a utilizar ao escrever o seu código de produção, devem ser adotadas também na hora de criar os testes.

O código de teste deve ser limpo e claro, pois, quando um teste quebra, o desenvolvedor irá até ele para entender o que ele faz e porque ele quebrou. Se a estrutura do teste estiver ruim, ou se estiver uma bagunça, o teste vai mais atrapalhar do que ajudar! A leitura e compreensão devem ser rápidas, então, preocupe-se com isso e crie um bom código!

Na minha vivência eu já vi de tudo, desde testes bem escritos e claros, e outros com estrutura muito ruins, que pra entender o que estava acontecendo ali, levou-se um precioso tempo de leitura. Já cheguei ao ponto de ter que debugar pra entender o que o teste estava fazendo e porque ele quebrou. Difícil né?

Repare que, se você está se deparando com um código de teste ruim, provavelmente o código que ele testa pode também estar mal estruturado. Isso ocorre com mais frequência quando há maior acoplamento entre as classes, fazendo com que você tenha que criar várias e várias instâncias de outras classes para passar como parâmetro pro método que será testado.

Lembre-se de que você escreve o código que outros devs lerão no futuro, e este código tem que ajudar eles para que esta prática tenha sucesso!

Conclusão

A minha conclusão é que, é sempre possível criar testes de unidade, mesmo lidando com código legado que possua uma estrutura ruim e amarrada (código macarronada). Existem técnicas que podem ser aplicadas, refatoração (refactoring), reescrita, etc.

O que não pode acontecer é a desistência! Na equipe que eu trabalho já passamos por alguns momentos de crise com os testes. Porém, seguimos em frente e, desde que implantamos, criamos cerca de 3.000 testes! Estes testes atualmente nos ajudam muito, principalmente em funcionalidades que estão 100% cobertas de testes.

Se você possui um sistema grande e que pertente começar a implementar teste de unidade, saiba que é um investimento que demora a dar “lucro”, mas no futuro, terá valido a pena!

Se você de alguma forma precisar de ajuda ou de orientação, ou quem sabe, bater um papo sobre testes, não hesite em entrar em contato comigo! Você pode entrar em contato comigo acessando esta página: Entrar em contato.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.