Série da semana: Primeiros passos no Angular

Veja mais

Vale a pena usar teste unitário? Se sim por quê?

17/09/2018

6

Fala Galera!

Testar todo mundo testa, não é mesmo? Nem que seja exibindo o valor de um método através de um print na tela ou algo do tipo! Vocês acham que vale a pena utilizar alguma metodologia profissional de testes, como por exemplo teste unitário? Isso de fato traz algum benefício?

Vamos conversar!
Responder

Post mais votado

17/09/2018

Sim, é claro que vale.
Testes unitários são uma mão na roda para você testar sua aplicação. E ainda mais que, se você estiver trabalhando com uma equipe, qualquer integrante dessa equipe pode usar os mesmos testes. Se os testes são bem implementados e estão realmente corretos, vai economizar um tempo precioso cada vez que você ou outro membro da equipe precisar dar algum tipo de manutenção no sistema.
Por exemplo no Java, se você usa o Maven como gerenciador de build, toda vez que você constrói o artefato final o Maven pode executar automaticamente os testes e se tudo passar ele gera o artefato, caso tenha qualquer teste que não passe ele não gera e te avisa qual teste não passou.
Responder

Mais Posts

17/09/2018

Paulo Mendes

Sim. Testes unitários são importantes mas você não precisa implementa-los para cada pequena funcionalidade e sim escolher um conjunto das mais importantes ou propensas a erros.

Generalizando um pouco mais, não tem como testarmos tudo que uma aplicação se propõe a fazer pois fica inviável, daí a necessidade de projetar testes importantes, significativos
Responder

17/09/2018

Estevão Dias

Fala Paulo, blz?

Se eu entendi bem o que você quis dizer eu concordo. Seria buscar um cenário ideal de teste no qual são testados os pontos nos quais algumas das suas classes se encontram para realizar uma ação importante. Seria algo próximo do conceito de unidade de trabalho.
Responder

17/09/2018

Estevão Dias

Uma coisa que eu estava reparando ao ver as documentações dos [x]Units é que diferente do PyUnit o JUnit não tem suporte "nativo" a mockagem. Alguma vez você já precisou disso ou fez falta, Márcio?
Responder

17/09/2018

Marcio Souza

Isso mesmo Estavão, JUnit não tem mock, mas no java tem a biblioteca Mockito que é integrada ao JUnit para esse tipo de testes. Eu particularmente não gosto muito de criar mocks, eu prefiro, por exemplo, ter uma base de dados em memória e fazer os testes sobre esses dados. Mas as vezes é preciso ter um mock para inicializar os testes com alguns tipos de dados, dai não tem o que fazer.

Agora, discordo do Paulo, teste é teste. Como na escola, no teste cai toda a matéria. Em aplicações, até mesmo uma pequena funcionalidade pode causar um erro ou lançar uma exceção. Um exemplo disso são os incontáveis NullPointerException que muita gente toma ao longo da vida. Não tem operação mais simples do que instanciar um objeto, mas mesmo assim, da-lhe NullPointerException.

O ideal nos testes é não deixar para depois se pretende usá-lo. A cada módulo ou camada desenvolvida já vá paralelamente desenvolvendo os testes para cada um dos métodos. Uma vez tudo testado, passe para o próximo módulo ou camada.
Responder

18/09/2018

Caio Rolla

E como podemos testar os models de uma aplicação? Existe alguma forma de testar sem precisar criar um banco de testes?
Responder

18/09/2018

Paulo Mendes

Agora, discordo do Paulo, teste é teste. Como na escola, no teste cai toda a matéria. Em aplicações, até mesmo uma pequena funcionalidade pode causar um erro ou lançar uma exceção. Um exemplo disso são os incontáveis NullPointerException que muita gente toma ao longo da vida. Não tem operação mais simples do que instanciar um objeto, mas mesmo assim, da-lhe NullPointerException.


Há uma explicação do Pressman pra isso. De que é inviável testarmos cada 'if' em uma aplicação porque as possibilidades crescem exponencialmente. Claro, se for algo simples é diferente mas ele fala de aplicações grandes. No capítulo de testes.
Responder
O Paulo e o Ballem tocaram uma questão bem interessante que é a da cobertura de código.
Costumo ouvir que cobertura de código é igual bacon na comida: quanto mais melhor, porém há quem diga que muito dos casos entre 70% e 90% já é algo próximo do ideal.
O que vocês acham?
Responder

18/09/2018

Marcio Souza

Sim Caio, nesse caso você cria Mocks para substituir os dados de um banco. Aqui tem um artigo sobre o assunto - https://www.devmedia.com.br/mocks-introducao-a-automatizacao-de-testes-com-mock-object/30641 -
Responder

18/09/2018

Marcio Souza

O Paulo e o Ballem tocaram uma questão bem interessante que é a da cobertura de código.
Costumo ouvir que cobertura de código é igual bacon na comida: quanto mais melhor, porém há quem diga que muito dos casos entre 70% e 90% já é algo próximo do ideal.
O que vocês acham?


Aylan, se você testar entre 70% e 90% as chances da sua aplicação não ter erro no final do processo é bastante grande. Mas suponha que você teste 85%, e os outros 15% vão ficar como? Vai esperar que os erros estourem na cara do cliente ou dos usuários finais para ver que aqueles 15% tinham erro?
É por isso que muitas empresas tem equipes especialistas em testes. Os caras estão lá só para testar as aplicações. Você desenvolve, faz seus testes, aqueles que acha necessário, mas depois cai lá na equipe de testes e eles cobrem tudo. Então pode haver essa divisão de responsabilidades.

Como atualmente o desenvolvimento de softwares está muito baseado em metodologias ágeis, essas metodologias também acabam beneficiando os testes, porque você vai entregar partes menores do projeto por vez, tendo menos testes a se fazer a cada vez.
Responder

19/09/2018

Caio Rolla

O Paulo e o Ballem tocaram uma questão bem interessante que é a da cobertura de código.
Costumo ouvir que cobertura de código é igual bacon na comida: quanto mais melhor, porém há quem diga que muito dos casos entre 70% e 90% já é algo próximo do ideal.
O que vocês acham?

Aylan, se você testar entre 70% e 90% as chances da sua aplicação não ter erro no final do processo é bastante grande. Mas suponha que você teste 85%, e os outros 15% vão ficar como? Vai esperar que os erros estourem na cara do cliente ou dos usuários finais para ver que aqueles 15% tinham erro?
É por isso que muitas empresas tem equipes especialistas em testes. Os caras estão lá só para testar as aplicações. Você desenvolve, faz seus testes, aqueles que acha necessário, mas depois cai lá na equipe de testes e eles cobrem tudo. Então pode haver essa divisão de responsabilidades.

Como atualmente o desenvolvimento de softwares está muito baseado em metodologias ágeis, essas metodologias também acabam beneficiando os testes, porque você vai entregar partes menores do projeto por vez, tendo menos testes a se fazer a cada vez.



Faz sentido, mas é possível? Na vida real, você costuma ver softwares com 100% de cobertura de testes?
Responder

19/09/2018

Estevão Dias

Sim, é possível. E caso a equipe de desenvolvedores não dê conta existem empresas especializadas nesse assunto. O que também abre uma oportunidade de carreira pouco explorada (talvez?), a de analista de testes, programadores especializados em escrever testes para aplicações.
Responder

20/09/2018

Estevão Dias

Um forma de ingressar nessa carreira é através de projetos de código aberto. Grandes projetos possuem uma porta aberta para programadores que desejam testes candidatos a publicação e reportar problemas no código. Mesmo aqueles não possuem em sua página inicial costumam acompanhar os problemas reportados pela comunidade em sua página de issues no GitHub ou JIRA:

https://github.com/spring-projects/spring-framework-issues

Alguns projetos de código aberto utilizam esse processo para selecionar candidatos e incorporar novos programadores ao time de desenvolvimento, fazendo com que eles passem primeiro pela etapa de encontrar problemas em funcionalidades recém programadas.
Responder

21/09/2018

Hugo Silva

Com certeza.

Você deve sempre implementar seus testes unitários para as regras de negócio da sua aplicação, isso vai fazer com que rode os teste antes de subir uma aplicação para o seu cliente, principalmente quando você vai entregar um artefato, para ter que evitar testar tudo no braço.
Responder
Com certeza.

Você deve sempre implementar seus testes unitários para as regras de negócio da sua aplicação, isso vai fazer com que rode os teste antes de subir uma aplicação para o seu cliente, principalmente quando você vai entregar um artefato, para ter que evitar testar tudo no braço.


Concordo plenamente.
Como vocês costumam fazer quando é necessário a implantação do teste unitário em um sistema legado que está em produção?
Responder

25/09/2018

Caio Rolla


Concordo plenamente.
Como vocês costumam fazer quando é necessário a implantação do teste unitário em um sistema legado que está em produção?


Eu não costumo modificar coisas que estejam funcionando em produção, a não ser que seja requisitado ou aconteça algum problema. Mas novas funcionalidades devem ser testadas, com certeza.
Responder