Vale a pena usar teste unitário? Se sim por quê?
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!
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!
Aylan Boscarino
Curtidas 1
Melhor post
Marcio Souza
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.
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.
GOSTEI 5
Mais Respostas
Paulo Mendes
17/09/2018
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
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
GOSTEI 1
Estevão Dias
17/09/2018
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.
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.
GOSTEI 0
Estevão Dias
17/09/2018
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?
GOSTEI 0
Marcio Souza
17/09/2018
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.
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.
GOSTEI 1
Caio Rolla
17/09/2018
E como podemos testar os models de uma aplicação? Existe alguma forma de testar sem precisar criar um banco de testes?
GOSTEI 0
Paulo Mendes
17/09/2018
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.
GOSTEI 0
Aylan Boscarino
17/09/2018
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?
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?
GOSTEI 0
Marcio Souza
17/09/2018
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 -
GOSTEI 0
Marcio Souza
17/09/2018
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?
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.
GOSTEI 0
Caio Rolla
17/09/2018
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.
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?
GOSTEI 0
Estevão Dias
17/09/2018
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.
GOSTEI 0
Estevão Dias
17/09/2018
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.
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.
GOSTEI 1
Hugo Silva
17/09/2018
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.
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.
GOSTEI 0
Aylan Boscarino
17/09/2018
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.
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?
GOSTEI 0
Caio Rolla
17/09/2018
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.
GOSTEI 0
Estevão Dias
17/09/2018
Algumas APIs de teste permitem criar um método de teste sem corpo, informando que ele está incompleto. Dessa forma, sinalizamos a intenção de criar um teste para certa funcionalidade, mesmo que isso não possa ser feito no momento por algum fator limitante, uma situação muito comum em aplicações legadas.
Ao se valer desse mecanismo, uma vez que os métodos de teste incompletos ou não implementados são sinalizados na saída da execução de cada teste, o programador consegue aumentar aos poucos a cobertura de teste da aplicação, sem perder o foco do que ainda falta ser testado. Assim, você pode dividir o processo de teste de uma aplicação legado em dois passos. No primeiro você identifica o que deve ser testado e cria métodos incompletos para documentar esse processo e depois vai escrevendo esses testes aos poucos.
Ao se valer desse mecanismo, uma vez que os métodos de teste incompletos ou não implementados são sinalizados na saída da execução de cada teste, o programador consegue aumentar aos poucos a cobertura de teste da aplicação, sem perder o foco do que ainda falta ser testado. Assim, você pode dividir o processo de teste de uma aplicação legado em dois passos. No primeiro você identifica o que deve ser testado e cria métodos incompletos para documentar esse processo e depois vai escrevendo esses testes aos poucos.
GOSTEI 0
Estevão Dias
17/09/2018
Algumas APIs de teste permitem criar um método de teste sem corpo, informando que ele está incompleto. Dessa forma, sinalizamos a intenção de criar um teste para certa funcionalidade, mesmo que isso não possa ser feito no momento por algum fator limitante, uma situação muito comum em aplicações legadas.
Ao se valer desse mecanismo, uma vez que os métodos de teste incompletos ou não implementados são sinalizados na saída da execução de cada teste, o programador consegue aumentar aos poucos a cobertura de teste da aplicação, sem perder o foco do que ainda falta ser testado. Assim, você pode dividir o processo de teste de uma aplicação legado em dois passos. No primeiro você identifica o que deve ser testado e cria métodos incompletos para documentar esse processo e depois vai escrevendo esses testes aos poucos.
Ao se valer desse mecanismo, uma vez que os métodos de teste incompletos ou não implementados são sinalizados na saída da execução de cada teste, o programador consegue aumentar aos poucos a cobertura de teste da aplicação, sem perder o foco do que ainda falta ser testado. Assim, você pode dividir o processo de teste de uma aplicação legado em dois passos. No primeiro você identifica o que deve ser testado e cria métodos incompletos para documentar esse processo e depois vai escrevendo esses testes aos poucos.
GOSTEI 0
Estevão Dias
17/09/2018
Algumas APIs de teste permitem criar um método de teste sem corpo, informando que ele está incompleto. Dessa forma, sinalizamos a intenção de criar um teste para certa funcionalidade, mesmo que isso não possa ser feito no momento por algum fator limitante, uma situação muito comum em aplicações legadas.
Ao se valer desse mecanismo, uma vez que os métodos de teste incompletos ou não implementados são sinalizados na saída da execução de cada teste, o programador consegue aumentar aos poucos a cobertura de teste da aplicação, sem perder o foco do que ainda falta ser testado. Assim, você pode dividir o processo de teste de uma aplicação legado em dois passos. No primeiro você identifica o que deve ser testado e cria métodos incompletos para documentar esse processo e depois vai escrevendo esses testes aos poucos.
Ao se valer desse mecanismo, uma vez que os métodos de teste incompletos ou não implementados são sinalizados na saída da execução de cada teste, o programador consegue aumentar aos poucos a cobertura de teste da aplicação, sem perder o foco do que ainda falta ser testado. Assim, você pode dividir o processo de teste de uma aplicação legado em dois passos. No primeiro você identifica o que deve ser testado e cria métodos incompletos para documentar esse processo e depois vai escrevendo esses testes aos poucos.
GOSTEI 0