it-swarm-pt.tech

O teste de unidade vale o esforço?

Estou trabalhando para integrar o teste de unidade no processo de desenvolvimento da equipe em que trabalho e há alguns céticos. Quais são algumas boas maneiras de convencer os desenvolvedores céticos da equipe sobre o valor do Teste de Unidade? No meu caso específico, estaríamos adicionando testes de unidade à medida que adicionamos funcionalidade ou erros fixos. Infelizmente, nossa base de código não se presta a testes fáceis.

573
Ross Fuhrman

Todos os dias em nosso escritório há uma troca que é algo assim:

"Cara, eu simplesmente adoro os testes de unidade, eu apenas consegui fazer um monte de mudanças na maneira como algo funciona, e então eu confirmei que não tinha quebrado nada ao executar o teste novamente ..."

Os detalhes mudam diariamente, mas o sentimento não muda. Testes de unidade e desenvolvimento orientado a testes (TDD) têm tantos benefícios ocultos e pessoais, bem como os mais óbvios que você simplesmente não consegue explicar a alguém até que eles mesmos o façam.

Mas, ignorando isso, aqui está minha tentativa!

  1. Testes de unidade permite que você faça grandes alterações no código rapidamente. Você sabe que funciona agora porque você executou os testes, quando faz as alterações necessárias, precisa fazer os testes novamente. Isso economiza horas.

  2. O TDD ajuda você a perceber quando parar de codificar. Seus testes dão a você a confiança de que você já fez o suficiente por enquanto e pode parar de mexer e passar para a próxima coisa.

  3. Os testes e o código trabalham juntos para obter um código melhor. Seu código pode ser ruim/com bugs. Seu TESTE pode ser ruim/com bugs. Em TDD você está apostando nas chances de ambos serem ruins/com bugs baixos. Muitas vezes é o teste que precisa ser consertado, mas ainda é um bom resultado.

  4. O TDD ajuda na codificação da constipação. Quando se deparar com um trabalho grande e assustador, escrever os testes fará com que você se mova rapidamente.

  5. Os Testes de Unidade ajudam você a entender realmente o design do código em que você está trabalhando. Em vez de escrever código para fazer algo, você está começando descrevendo todas as condições para as quais você está submetendo o código e quais saídas você esperaria dele.

  6. Os Testes Unitários fornecem um feedback visual instantâneo, todos nós gostamos da sensação de todas aquelas luzes verdes quando terminamos. É muito satisfatório. Também é muito mais fácil continuar de onde você parou depois de uma interrupção, porque você pode ver onde você chegou - a próxima luz vermelha que precisa ser consertada.

  7. Ao contrário do teste de unidade de crença popular, não significa escrever o dobro do código ou codificar mais lentamente. É mais rápido e mais robusto do que codificar sem testes depois que você se acostumar com isso. O código de teste em si é relativamente trivial e não adiciona uma grande sobrecarga ao que você está fazendo. Este é um que você só vai acreditar quando estiver fazendo isso :)

  8. Acho que foi Fowler quem disse: "Testes imperfeitos, feitos com frequência, são muito melhores que testes perfeitos que nunca são escritos". Eu interpreto isso como me dando permissão para escrever testes onde eu acho que eles serão mais úteis, mesmo se o resto da minha cobertura de código estiver lamentavelmente incompleta.

  9. Bons testes de unidade podem ajudar a documentar e definir o que algo deve fazer

  10. Testes unitários ajudam na reutilização de código. Migre seu código e seus testes para o seu novo projeto. Ajuste o código até que os testes sejam executados novamente.

Muito trabalho com o qual estou envolvido não faz o Unit Test bem (interações de usuários de aplicativos da web, etc.), mas mesmo assim todos nós estamos infectados por testes nesta loja, e mais felizes quando temos nossos testes amarrados. Eu não posso recomendar a abordagem altamente suficiente.

722
reefnet_alex

O teste unitário é muito parecido com ir ao ginásio. Você sabe que é bom para você, todos os argumentos fazem sentido, então você começa a trabalhar. Há um Rush inicial, que é ótimo, mas depois de alguns dias você começa a se perguntar se vale a pena. Você está tirando uma hora do seu dia para trocar de roupa e correr em uma roda de hamster e você não tem certeza se realmente está ganhando outra coisa senão pernas e braços doloridos.

Então, depois de uma ou duas semanas, assim que a dor estiver desaparecendo, um Big Deadline se aproxima. Você precisa passar todas as horas de vigília tentando fazer um trabalho "útil", então você corta coisas estranhas, como ir ao ginásio. Você sai do hábito e, quando o Big Deadline termina, você volta à estaca zero. Se você conseguir voltar para a academia, você se sentirá tão dolorido quanto estava na primeira vez que foi.

Você faz algumas leituras para ver se está fazendo algo errado. Você começa a sentir um pouco de irracional irracional em relação a todas as pessoas felizes e em forma que exaltam as virtudes do exercício. Você percebe que não tem muito em comum. Eles não têm que dirigir 15 minutos fora do caminho para ir ao ginásio; há um em seu prédio. Eles não precisam discutir com ninguém sobre os benefícios do exercício; é apenas algo que todo mundo faz e aceita como importante. Quando um grande prazo se aproxima, eles não são informados de que o exercício é desnecessário mais do que o seu chefe pediria para você parar de comer.

Então, para responder à sua pergunta, o Teste de Unidade geralmente vale o esforço, mas a quantidade de esforço necessário não será a mesma para todos. O Teste de Unidade pode exigir uma enorme quantidade de esforço se você estão lidando com base de código de espaguete em uma empresa que não realmente qualidade do código de valor. (Muitos gerentes vão elogiar o teste de unidade, mas isso não significa que eles vão se defender quando for importante).

Se você está tentando introduzir o Teste Unitário em seu trabalho e não está vendo toda a luz do sol e arco-íris que você foi levado a esperar, não se culpe. Talvez seja necessário encontrar um novo trabalho para realmente fazer o Teste de Unidade funcionar para você.

421
benzado

Melhor maneira de convencer ... encontrar um bug, escrever um teste de unidade para ele, corrigir o bug.

É improvável que esse bug em particular apareça novamente, e você pode provar isso com seu teste.

Se você fizer isso o suficiente, os outros vão pegar rapidamente.

136
Ed Guiness

thetalkingwalnut pergunta:

Quais são algumas boas maneiras de convencer os desenvolvedores céticos da equipe sobre o valor do Teste de Unidade?

Todo mundo aqui vai acumular muitas razões por que o teste de unidade é bom. No entanto, eu acho que muitas vezes a melhor maneira de convencer alguém de alguma coisa é ouvir o seu argumento e abordá-lo ponto por ponto. Se você ouvir e ajudá-los a verbalizar suas preocupações, você pode abordar cada um deles e, talvez, convertê-los ao seu ponto de vista (ou, no mínimo, deixá-los sem uma perna para ficar em pé). Quem sabe? Talvez eles te convençam porque os testes de unidade não são apropriados para a sua situação. Não é provável, mas possível. Talvez, se você publicar seus argumentos contra testes de unidade, possamos ajudar a identificar os contra-argumentos.

É importante ouvir e entender os dois lados do argumento. Se você tentar adotar testes de unidade com muito zelo sem levar em conta as preocupações das pessoas, você acabará com uma guerra religiosa (e provavelmente com testes unitários realmente inúteis). Se você adotá-lo lentamente e começar a aplicá-lo onde você verá o maior benefício pelo menor custo, poderá demonstrar o valor dos testes de unidade e ter uma melhor chance de convencer as pessoas. Eu percebo que isso não é tão fácil quanto parece - geralmente requer algum tempo e métricas cuidadosas para elaborar um argumento convincente.

Testes de unidade são uma ferramenta, como qualquer outra, e devem ser aplicados de tal forma que os benefícios (erros de captura) superem os custos (o esforço de escrevê-los). Não os use se/onde eles não fizerem sentido e lembre-se de que eles são apenas parte de seu arsenal de ferramentas (por exemplo, inspeções, asserções, analisadores de código, métodos formais, etc.). O que eu digo aos meus desenvolvedores é isso:

  1. Eles podem pular escrevendo um teste para um método se tiverem um bom argumento porque não é necessário (por exemplo, simples demais para valer a pena ou muito difícil de valer a pena) e como o método será verificado (por exemplo, inspeção, afirmações , métodos formais, testes interativos/integração). Eles precisam considerar que algumas verificações como inspeções e provas formais são feitas em um ponto no tempo e então precisam ser repetidas toda vez que o código de produção muda, enquanto testes unitários e asserções podem ser usados ​​como testes de regressão (escritos uma vez e executados repetidamente a partir de então). ). Às vezes eu concordo com eles, mas com mais frequência eu vou debater se um método é realmente muito simples ou muito difícil para o teste de unidade.

    • Se um desenvolvedor argumentar que um método parece simples demais para falhar, não vale a pena tirar os 60 segundos necessários para escrever um simples teste de 5 linhas para ele? Essas 5 linhas de código serão executadas todas as noites (você faz construções noturnas, certo?) Pelo próximo ano ou mais e valerá o esforço se, mesmo uma vez, ocorrer um problema que pode levar 15 minutos ou mais para identificar e depurar. Além disso, escrever os testes unitários fáceis aumenta a contagem de testes unitários, o que faz com que o desenvolvedor tenha uma boa aparência.

    • Por outro lado, se um desenvolvedor argumentar que um método parece muito difícil para o teste unitário (não vale a pena o esforço significativo necessário), talvez isso seja uma boa indicação de que o método precisa ser dividido ou refatorado para testar as partes fáceis. Geralmente, esses são métodos que dependem de recursos incomuns, como singletons, a hora atual ou recursos externos, como um conjunto de resultados de banco de dados. Esses métodos geralmente precisam ser refatorados em um método que obtém o recurso (por exemplo, chamadas getTime ()) e um método que usa o recurso como um argumento (por exemplo, usa o registro de data e hora como parâmetro). Eu deixo eles pularem o teste do método que recupera o recurso e eles, em vez disso, escrevem um teste de unidade para o método que agora usa o recurso como um argumento. Geralmente, isso torna a escrita do teste de unidade muito mais simples e, portanto, vale a pena escrever.

  2. O desenvolvedor precisa desenhar uma "linha na areia" na abrangência de seus testes unitários. Mais tarde, no desenvolvimento, sempre que encontrarmos um erro, eles devem determinar se testes unitários mais abrangentes teriam detectado o problema. Se sim, e se esses bugs surgirem repetidamente, eles precisam mover a "linha" para escrever testes unitários mais abrangentes no futuro (começando com a adição ou expansão do teste de unidade para o bug atual). Eles precisam encontrar o equilíbrio certo.

É importante perceber que os testes de unidade não são uma bala de prata e que é algo como testes de unidade demais. No meu local de trabalho, sempre que fazemos as lições aprendidas, eu inevitavelmente ouço "precisamos escrever mais testes de unidade". Gestão concorda com a cabeça porque foi batido em suas cabeças que "testes unitários" = "bom".

No entanto, precisamos entender o impacto de "mais testes de unidade". Um desenvolvedor pode escrever apenas ~ N linhas de código por semana e você precisa descobrir qual porcentagem desse código deve ser código de teste de unidade versus código de produção. Um local de trabalho laxista pode ter 10% do código como testes de unidade e 90% do código como código de produção, resultando em um produto com muitos recursos (embora com muito bugs) (pense no MS Word). Por outro lado, uma loja rigorosa com 90% de testes unitários e 10% de código de produção terá um produto sólido com poucos recursos (pense em "vi"). Você pode nunca ouvir relatórios sobre o último produto falhando, mas isso provavelmente tem tanto a ver com o produto que não está vendendo muito bem quanto tem a ver com a qualidade do código.

Pior ainda, talvez a única certeza no desenvolvimento de software seja que "a mudança é inevitável". Suponha que a loja restrita (90% de testes unitários/10% de código de produção) crie um produto que tenha exatamente 2 recursos (assumindo 5% do código de produção == 1 recurso). Se o cliente chegar e alterar 1 dos recursos, essa alteração trashará 50% do código (45% dos testes de unidade e 5% do código de produção). A loja frouxa (10% de testes unitários/90% de código de produção) tem um produto com 18 características, e nenhuma delas funciona muito bem. Seu cliente renova completamente os requisitos para 4 de seus recursos. Mesmo que a mudança seja 4 vezes maior, apenas metade da base de código é descartada (~ 25% = ~ 4,4% de testes unitários + 20% do código de produção).

Meu ponto é que você tem que comunicar que você entende o equilíbrio entre muito pouco e muito teste de unidade - essencialmente que você pensou em ambos os lados da questão. Se você conseguir convencer seus colegas e/ou sua administração disso, você ganhará credibilidade e talvez tenha mais chances de conquistá-los.

69
Bert F

Brinquei várias vezes com o teste de unidade, e ainda estou convencido de que vale a pena o esforço dado a minha situação.

Desenvolvo sites, onde grande parte da lógica envolve a criação, recuperação ou atualização de dados no banco de dados. Quando tentei "ridicularizar" o banco de dados para fins de teste de unidade, ele ficou muito confuso e pareceu um pouco inútil.

Quando escrevo testes de unidade em torno da lógica de negócios, isso nunca me ajudou muito a longo prazo. Como trabalho em grande parte somente em projetos, tenho a tendência de saber intuitivamente quais áreas do código podem ser afetadas por algo em que estou trabalhando e testar essas áreas manualmente. Quero entregar uma solução ao meu cliente o mais rápido possível, e o teste da unidade geralmente parece uma perda de tempo. Eu listo os testes manuais e ando por eles, assinalando-os quando vou.

Eu posso ver que isso pode ser benéfico quando uma equipe de desenvolvedores está trabalhando em um projeto e atualizando o código um do outro, mas mesmo assim eu acho que se os desenvolvedores são de alta qualidade, boa comunicação e código bem escrito devem ser suficientes .

38
Ronnie

Uma ótima coisa sobre testes de unidade é que eles servem como documentação de como seu código deve se comportar. Bons testes são como uma implementação de referência e os colegas de equipe podem vê-los para ver como integrar seu código ao seu.

31
pkaeding

O teste unitário vale bem o investimento inicial. Desde que comecei a usar o teste de unidade há alguns anos, descobri alguns benefícios reais:

  • teste de regressão remove o medo de fazer alterações no código (não há nada como o brilho quente de ver o código funcionar ou explodir toda vez que uma alteração é feita)
  • exemplos de código executável para outros membros da equipe (e para você em seis meses)
  • impiedoso refatoração - isso é incrivelmente gratificante, tente!

Os snippets de código podem ser de grande ajuda para reduzir a sobrecarga da criação de testes. Não é difícil criar fragmentos que permitem a criação de um esboço de classe e um equipamento de teste unitário associado em segundos.

26
Jonathan Webb

Você deve testar o mínimo possível!

ou seja, você deve escrever apenas testes de unidade suficientes para revelar a intenção. Isso geralmente fica encoberto. O teste unitário custa você. Se você fizer alterações e tiver que alterar os testes, será menos ágil. Mantenha os testes de unidade curtos e doces. Então eles têm muito valor.

Muitas vezes eu vejo muitos testes que nunca vão quebrar, são grandes e desajeitados e não oferecem muito valor, eles acabam atrasando você.

25
Keith Nicholas

Eu não vi isso em nenhuma das outras respostas, mas uma coisa que eu notei é que eu poderia depurar muito mais rápido. Você não precisa detalhar seu aplicativo com a sequência correta de etapas para obter o código de sua correção, apenas para descobrir que você cometeu um erro booleano e precisa fazer tudo novamente. Com um teste de unidade, você pode simplesmente entrar diretamente no código que está depurando.

23
John MacIntyre

[Eu tenho um ponto para fazer isso eu não posso ver acima]

"Todos os testes unitários, eles não necessariamente percebem isso - FATO"

Pense nisso, você escreve uma função para talvez analisar uma string e remover novos caracteres de linha. Como um desenvolvedor novato, você pode executar alguns casos através da linha de comando, implementando-o no Main () ou conectar um front-end visual com um botão, amarrar sua função em algumas caixas de texto e um botão e ver o que acontece.

Isso é teste de unidade - básico e mal montado, mas você testa o pedaço de código para alguns casos.

Você escreve algo mais complexo. Ele gera erros quando você lança alguns casos por meio de (teste de unidade) e depura o código e rastreia. Você olha os valores à medida que passa e decide se estão certos ou errados. Este é um teste de unidade em algum grau.

O teste unitário aqui está realmente tomando esse comportamento, formalizando-o em um padrão estruturado e salvando-o para que você possa facilmente executar novamente esses testes. Se você escrever um caso de teste de unidade "adequado" ao invés de testar manualmente, ele leva o mesmo tempo, ou talvez menos, do que você experimenta, e você o tem disponível para repetir uma e outra vez

21
Chris Gill

Durante anos, tentei convencer as pessoas de que precisavam escrever um teste de unidade para seu código. Se eles escreveram os testes primeiro (como no TDD) ou depois de codificarem a funcionalidade, eu sempre tentei explicar-lhes todos os benefícios de ter testes de unidade para o código. Quase ninguém discordou de mim. Você não pode discordar de algo que é óbvio, e qualquer pessoa inteligente verá os benefícios do teste de unidade e do TDD.

O problema com o teste de unidade é que requer uma mudança comportamental e é muito difícil mudar o comportamento das pessoas. Com palavras, você terá muitas pessoas para concordar com você, mas você não verá muitas mudanças na forma como elas fazem as coisas.

Você tem que convencer as pessoas fazendo. Seu sucesso pessoal atrairá mais pessoas do que todos os argumentos que você possa ter. Se eles virem que você não está falando apenas de teste de unidade ou TDD, mas você está fazendo o que você prega, e você é bem-sucedido, as pessoas tentarão imitá-lo.

Você também deve assumir um papel de liderança, pois ninguém escreve o teste de unidade corretamente na primeira vez, então você pode precisar orientá-los sobre como fazer isso, mostrar a eles o caminho e as ferramentas disponíveis para eles. Ajude-os enquanto eles escrevem seus primeiros testes, revise os testes que eles escrevem sozinhos e mostre a eles os truques, expressões idiomáticas e padrões que você aprendeu através de suas próprias experiências. Depois de um tempo, eles começarão a ver os benefícios por conta própria e mudarão seu comportamento para incorporar testes de unidade ou TDD em sua caixa de ferramentas.

As mudanças não acontecem durante a noite, mas com um pouco de paciência, você pode atingir seu objetivo.

16
Curro

Uma parte importante do desenvolvimento orientado a testes, que muitas vezes é encoberto, é a criação de código testável. Parece algum tipo de compromisso no início, mas você descobrirá que o código testável também é modular, passível de manutenção e legível. Se você ainda precisa de ajuda para convencer as pessoas this é uma apresentação simples e agradável sobre as vantagens do teste unitário.

12
Tom Martin

Se a sua base de código existente não se presta a testes de unidade e já está em produção, você pode criar mais problemas do que resolve tentando refatorar todo o seu código para que seja testável em unidade.

Você pode ser melhor colocar esforços no sentido de melhorar seu teste de integração. Há muito código lá fora que é mais simples de escrever sem um teste de unidade, e se um QA puder validar a funcionalidade em relação a um documento de requisitos, então você está pronto. Enviá-lo.

O exemplo clássico disso em minha mente é um SqlDataReader incorporado em uma página ASPX vinculada a um GridView. O código está todo no arquivo ASPX. O SQL está em um procedimento armazenado. O que você teste de unidade? Se a página faz o que é suposto fazer, você realmente deveria reprojetá-la em várias camadas para ter algo para automatizar?

11
Eric Z Beard

Uma das melhores coisas sobre o teste de unidade é que seu código ficará mais fácil de ser testado à medida que você o faz. Código pré-criado criado sem testes é sempre um desafio porque, como eles não foram testados em unidades, não é raro ter um alto nível de acoplamento entre classes, objetos difíceis de configurar dentro de sua classe - como um e-mail. enviando referência de serviço - e assim por diante. Mas não deixe isso te derrubar! Você verá que o design geral do código ficará melhor à medida que você começar a escrever testes unitários e, quanto mais você testar, mais confiante ficará em fazer ainda mais alterações sem ter que interromper seu aplicativo ou apresentar erros. .

Existem várias razões para testar seu código em unidade, mas à medida que o tempo avança, você descobrirá que o tempo economizado em testes é uma das melhores razões para fazê-lo. Em um sistema que acabei de entregar, insisti em fazer testes unitários automatizados, apesar das afirmações de que gastaria muito mais tempo fazendo os testes do que testando o sistema manualmente. Com todos os meus testes de unidade feitos, executo mais de 400 casos de teste em menos de 10 minutos, e toda vez que eu tive que fazer uma pequena alteração no código, tudo o que eu precisava para ter certeza de que o código ainda estava funcionando era 10 minutos. Você pode imaginar o tempo que você gastaria para executar esses 400+ testes manualmente?

Quando se trata de testes automatizados - seja teste de unidade ou teste de aceitação - todos acham que é um esforço desperdiçado codificar o que você pode fazer manualmente, e às vezes é verdade - se você planeja executar seus testes apenas uma vez. A melhor parte do teste automatizado é que você pode executá-los várias vezes sem esforço, e após a segunda ou terceira execução, o tempo e o esforço que você desperdiçou já está pago.

Um último conselho seria não apenas testar seu código, mas começar a fazer o teste primeiro (veja TDD e BDD para mais)

10
Alexandre Brasil

Testes de unidade também são especialmente úteis quando se trata de refatorar ou reescrever uma peça de código. Se você tiver uma boa cobertura de testes de unidade, poderá refatorar com confiança. Sem testes de unidade, muitas vezes é difícil garantir que você não quebre nada.

8
killdash10

Estou trabalhando como engenheiro de manutenção de uma base de código mal documentada, horrível e grande. Eu gostaria que as pessoas que escreveram o código tivessem escrito os testes unitários para isso.
Cada vez que faço uma alteração e atualizo o código de produção, tenho medo de poder apresentar um bug por não ter considerado alguma condição.
Se eles escrevessem o teste, fazer mudanças na base de código seria mais fácil e rápido (ao mesmo tempo, a base de código estaria em um estado melhor).

Eu acho que os testes de unidade são muito úteis quando se está escrevendo APIs ou frameworks que duram por muitos anos e para serem usados ​​/ modificados/evoluídos por outras pessoas além dos codificadores originais.

7
mic.sca

Em suma - sim. Eles valem cada grama de esforço ... até certo ponto. Os testes são, no final do dia, ainda código, e muito parecido com o típico crescimento de código, seus testes precisarão ser refatorados para serem sustentáveis ​​e sustentáveis. Há uma tonelada de GOTCHAS! quando se trata de testes unitários, mas o homem oh oh man oh, nada, e eu quero dizer nada permite um desenvolvedor para fazer alterações com mais confiança do que um rico conjunto de testes unitários.

Eu estou trabalhando em um projeto agora ... é um pouco TDD, e temos a maioria das nossas regras de negócios encapsuladas como testes ... temos cerca de 500 ou mais testes de unidade agora. Esta última interação eu tive que renovar a nossa fonte de dados e como o nosso aplicativo de desktop interage com essa fonte de dados. Demorei alguns dias, o tempo todo eu continuei fazendo testes de unidade para ver o que eu havia quebrado e consertado. Faça uma mudança; Construa e execute seus testes; consertar o que você quebrou. Lave, enxágue, repita conforme necessário. O que tradicionalmente levaria dias de QA e cargas de barco de estresse era, em vez disso, uma experiência curta e agradável.

Faça um preparo antecipado, um pouco mais de esforço, e ele paga 10 vezes mais tarde quando você precisar começar a usar os principais recursos/funcionalidades.

Eu comprei este livro - é uma Bíblia de conhecimento do XUnit Testing - é provavelmente um dos livros mais referenciados na minha estante, e eu o consulto diariamente: link text

7
cranley

Ocasionalmente, eu ou um de meus colegas de trabalho gastamos algumas horas chegando ao fundo de um bug um pouco obscuro e uma vez que a causa do bug é encontrada 90% do tempo em que o código não é testado na unidade. O teste de unidade não existe porque o dev está cortando cantos para economizar tempo, mas perde isso e mais depuração.

Tomando a pequena quantidade de tempo para escrever um teste de unidade pode economizar horas de depuração no futuro.

7
Jon Cahill

Quando você disse, "nossa base de código não se presta a testes fáceis" é o primeiro sinal de um cheiro de código. Escrever Testes de Unidades significa que você costuma escrever código de maneira diferente, a fim de tornar o código mais testável. Isso é uma coisa boa, na minha opinião, o que eu tenho visto ao longo dos anos em escrever código para o qual eu tive que escrever testes, me forçou a fazer um design melhor.

6
Keith Elder

Eu não sei. Muitos lugares não fazem teste de unidade, mas a qualidade do código é boa. A Microsoft faz teste de unidade, mas Bill Gates deu uma tela azul em sua apresentação.

6
BigTiger

Teste unitário é definitivamente vale o esforço. Infelizmente você escolheu um cenário difícil (mas infelizmente comum) para implementá-lo.

O melhor benefício do teste de unidade que você obterá é ao usá-lo de baixo para cima - em alguns projetos pequenos selecionados, eu tive a sorte de escrever meus testes de unidade antes de implementar minhas classes (a interface já estava completa neste momento). ponto). Com os testes de unidade adequados, você encontrará e corrigirá bugs em suas aulas enquanto eles ainda estão na infância e não em qualquer lugar perto do complexo sistema no qual eles sem dúvida se integrarão no futuro.

Se o seu software é solidamente orientado a objetos, você deve ser capaz de adicionar testes unitários em nível de classe sem muito esforço. Se você não é tão afortunado, ainda deve tentar incorporar o teste de unidade sempre que puder. Certifique-se de que quando você adiciona uma nova funcionalidade, as novas peças são bem definidas com interfaces claras e você verá que o teste de unidade torna sua vida muito mais fácil.

6
Matt

Eu escrevi um post muito grande sobre o assunto. Descobri que o teste de unidade sozinho não vale o trabalho e geralmente é cortado quando os prazos se aproximam.

Em vez de falar sobre o teste de unidade do ponto de vista de verificação "teste após", devemos observar o valor real encontrado quando você decidiu escrever uma especificação/teste/ideia antes da implementação.

Essa ideia simples mudou a forma como eu escrevo software e não voltaria à maneira "antiga".

Como o primeiro desenvolvimento do teste mudou minha vida

5
Toran Billups

Uma coisa que ninguém mencionou ainda é ter o compromisso de todos os desenvolvedores de realmente executar e atualizar qualquer teste automatizado existente. Os testes automatizados que você recupera e descobre devido a novos desenvolvimentos perdem muito valor e tornam os testes automatizados realmente dolorosos. A maioria desses testes não indicará bugs, pois o desenvolvedor testou o código manualmente, então o tempo gasto na atualização é apenas um desperdício.

Convencer os céticos a não destruir o trabalho que os outros estão fazendo nos testes de unidade é muito mais importante para obter valor dos testes e pode ser mais fácil.

Passar horas atualizando testes que foram interrompidos devido a novos recursos cada vez que você atualiza a partir do repositório não é nem produtivo nem divertido.

3
Samuel Åslund

Eu descobri o TDD há alguns anos e desde então escrevi todos os meus projetos de estimação usando ele. Eu estimei que leva aproximadamente o mesmo tempo para o TDD um projeto que leva ao cowboy juntos, mas eu tenho uma confiança tão grande no produto final que eu não posso evitar um sentimento de realização.

Eu também sinto que isso melhora meu estilo de design (muito mais orientado à interface no caso de eu precisar zombar das coisas) e, como escreve o post verde no topo, ajuda a "codificar constipação": quando você não sabe o que para escrever a seguir, ou você tem uma tarefa assustadora na frente de você, você pode escrever pequeno.

Finalmente, acho que de longe a aplicação mais útil de TDD está na depuração, mesmo porque você já desenvolveu uma estrutura de interrogatório com a qual você pode estimular o projeto a produzir o bug de uma maneira repetível.

3
Kaz Dragon

Sim - o Teste de Unidade definitivamente vale o esforço, mas você deve saber que não é uma bala de prata. O Teste Unitário é o trabalho e você terá que trabalhar para manter o teste atualizado e relevante como mudanças de código, mas o valor oferecido vale o esforço que você tem para colocar. A capacidade de refatorar com impunidade é um grande benefício, pois você sempre pode validar a funcionalidade executando seus testes após qualquer código de mudança. O truque é não ficar muito preso na unidade de trabalho que você está testando ou em como você está testando os requisitos de teste e quando um teste de unidade é realmente um teste funcional, etc. As pessoas vão discutir sobre essas coisas por horas no final e a realidade é que qualquer teste que você faz como seu código de escrita é melhor do que não fazê-lo. O outro axioma é sobre qualidade e não quantidade - eu vi bases de código com milhares de testes que são essencialmente sem sentido, já que o resto realmente não testa nada útil ou qualquer domínio específico como regras de negócio, etc. do domínio particular. Eu também vi codebases com 30% de cobertura de código, mas os testes foram relevantes, significativos e realmente incríveis, pois testaram a funcionalidade principal do código para o qual foi escrito e expressaram como o código deve ser usado.

Um dos meus truques favoritos ao explorar novas estruturas ou bases de código é escrever testes unitários para descobrir como as coisas funcionam. É uma ótima maneira de aprender mais sobre algo novo em vez de ler um documento seco :)

3
Vinny Carpenter

Recentemente, passei pela mesma experiência no meu local de trabalho e descobri que a maioria deles conhecia os benefícios teóricos, mas precisava ser vendida especificamente para os benefícios, então aqui estavam os pontos que usei (com sucesso):

  • Eles economizam tempo ao realizar testes negativos, onde você manipula entradas inesperadas (ponteiros nulos, valores fora dos limites, etc), como você pode fazer tudo isso em um único processo.
  • Eles fornecem feedback imediato em tempo de compilação sobre o padrão das mudanças.
  • Eles são úteis para testar representações de dados internos que podem não ser expostas durante o tempo de execução normal.

e o grande ...

  • Você pode não precisar de testes de unidade, mas quando alguém entra e modifica o código sem um entendimento completo, ele pode pegar muitos erros bobos que eles podem cometer.
3
dlanod

Pela minha experiência, testes de unidade e testes de integração são um "MUST HAVE" em ambientes de software complexos.

Para convencer os desenvolvedores de sua equipe a escrever testes de unidade, convém considerar a integração da análise de regressão de teste de unidade em seu ambiente de desenvolvimento (por exemplo, em seu processo de criação diário).

Uma vez que os desenvolvedores saibam que, se um teste de unidade falhar, eles não precisarão gastar muito tempo para depurá-lo para encontrar o problema, eles seriam mais incentivados a escrevê-lo.

Aqui está uma ferramenta que fornece tal funcionalidade:

ferramenta de análise de regressão de teste unitário

2
Liorp

Se você estiver usando o NUnit, uma demonstração simples, porém eficaz, é executar a (s) própria (s) suíte (s) de testes do NUnit na frente deles. Ver uma suíte de testes real dando uma base de código um treino vale mais que mil palavras ...

2
Garth Gilmour

A única coisa a ter em mente sobre o teste de unidade é que é um conforto para o desenvolvedor.

Em contraste, os testes funcionais são para os usuários: sempre que você adiciona um teste funcional, você está testando algo que o usuário verá. Quando você adiciona um teste de unidade, está apenas facilitando sua vida como desenvolvedor. É um pouco de luxo a esse respeito.

Mantenha essa dicotomia em mente quando você tiver que escolher entre escrever uma unidade ou um teste funcional.

2
Cedric Beust

Estou de acordo com o ponto de vista oposto à maioria aqui: Não há problema em escrever testes unitários Especialmente a programação pesada em protótipos (AI, por exemplo) é difícil de combinar com testes unitários.

2
DSblizzard

O teste de unidade ajuda muito em projetos que são maiores do que qualquer desenvolvedor pode ter em mente. Eles permitem que você execute o pacote de teste de unidade antes de checkin e descubra se você quebrou alguma coisa. Isso reduz um lote nos casos de ter que sentar e mexer seus polegares enquanto espera que alguém conserte um bug que ele registrou, ou o incômodo de reverter sua mudança para que você possa fazer algum trabalho. Também é imensamente valioso na refatoração, portanto, você pode ter certeza de que o código refatorado passa em todos os testes que o código original fez.

2
Max Rible Kaehn

Com o conjunto de testes de unidade, é possível fazer alterações no código, deixando o restante dos recursos intactos. É uma grande vantagem. Você usa a unidade de teste de teste e a suíte de teste de regressão sempre que terminar de codificar um novo recurso.

2
Shinwari

O objetivo do teste unitário é facilitar o teste. É automatizado. "faça teste" e pronto. Se um dos problemas que você enfrenta é difícil de testar o código, essa é a melhor razão para todos usarem o teste de unidade.

1
Deathbob

Ainda hoje tive que mudar uma classe para a qual um teste de unidade foi escrito anteriormente.
O teste em si foi bem escrito e incluiu cenários de teste que eu nem tinha pensado.
Felizmente, todos os testes foram aprovados e minha alteração foi rapidamente verificada e colocada no ambiente de teste com confiança.

1
crowne

Ao testar manualmente o software, você normalmente tem um pequeno conjunto de testes/ações que você usa. Eventualmente, você transformará automaticamente seus dados ou ações de entrada para navegar por problemas conhecidos. Testes de unidade devem estar lá para lembrá-lo de que as coisas não funcionam corretamente.

Eu recomendo escrever testes antes do código, adicionando novos testes/dados para evoluir a funcionalidade do código principal!

1
Ray Hayes

Como estudante de física, eu sou muito motivado a realmente provar que meu código funciona como deveria. Você pode provar isso logicamente, o que aumenta drasticamente a dificuldade à medida que a implementação se torna mais complexa, ou você pode fazer uma prova empírica da função (o mais próximo possível) por meio de bons testes.

Se você não fornecer prova lógica de função, terá que testar. A única alternativa é dizer "Eu acho que o código funciona ...."

1
Fredrik

@George Stocker "Infelizmente, nossa base de código não se presta a testes fáceis." Todos concordam que há benefícios para os testes unitários, mas parece que, para essa base de código, os custos são altos. Se os custos são maiores do que os benefícios, então por que eles deveriam estar entusiasmados com isso? Ouça seus colegas de trabalho; talvez para eles a dor percebida nos testes unitários seja maior do que o valor percebido dos testes unitários.

Especificamente, tente ganhar valor o mais rápido possível, e não algum valor "xUnit is green", mas código limpo que os usuários e mantenedores valorizam. Talvez você tenha que mandar testes unitários para uma iteração e depois discutir se vale a pena o esforço ou não.

1
Trystan Spangler

Faça as primeiras coisas que você testou não relacionadas ao teste de unidade. Eu trabalho principalmente em Perl, então esses são exemplos específicos do Perl, mas você pode se adaptar.

  • Todo módulo carrega e compila corretamente? Em Perl, isso é uma questão de criar um Foo.t para cada Foo.pm na base de código que faz:

    use_ok( 'Foo' );
    
  • Todo o POD (Documentação Plain Ol ') está formatado corretamente? Use Test :: Pod para validar a validade da formatação de todos os PODs em todos os arquivos.

Você pode não pensar que essas coisas são grandes, e elas não são, mas posso garantir que você vai pegar um pouco de lixo. Quando esses testes são executados uma vez por hora, e detecta o comprometimento prematuro de alguém, você faz as pessoas dizerem "Ei, isso é muito legal".

1
Andy Lester

Um dos benefícios do teste unitário é a previsibilidade.

Antes de testar a unidade, eu poderia prever com bastante precisão quanto tempo levaria para codificar algo, mas não quanto tempo eu precisaria para depurá-lo.

Hoje em dia, já que posso planejar os testes que vou escrever, sei quanto tempo a codificação vai levar e, ao final da codificação, o sistema já está depurado! Isso traz previsibilidade ao processo de desenvolvimento, o que elimina grande parte da pressão, mas ainda mantém toda a alegria !!.

1
Raz

O Unit Testing é uma das metodologias mais adotadas para código de alta qualidade. Sua contribuição para um código mais estável, independente e documentado está bem comprovada. O código de teste de unidade é considerado e tratado como parte integrante do seu repositório e, como tal, requer desenvolvimento e manutenção. No entanto, os desenvolvedores geralmente encontram uma situação em que os recursos investidos em testes de unidade não são tão proveitosos quanto se espera. Em um mundo ideal, cada método que codificamos terá uma série de testes cobrindo o código e validando a correção. No entanto, geralmente devido a limitações de tempo, podemos pular alguns testes ou escrever os de baixa qualidade. Em tal realidade, embora tendo em mente a quantidade de recursos investidos no desenvolvimento e manutenção de testes unitários, deve-se perguntar a si mesmo, dado o tempo disponível, qual código merece mais ser testado? E dos testes existentes, quais testes realmente valem manter e manter? Veja aqui

0
RoiG

Os testes unitários ajudam você a lançar softwares com menos bugs, reduzindo os custos gerais de desenvolvimento. Você pode clicar no link para ler mais sobre o benefícios do teste unitário

0
Steve_0

Quem você está tentando convencer? Engenheiros ou gerente? Se você está tentando convencer seus colegas de trabalho de engenheiros, acho que sua melhor aposta é apelar para o desejo de criar um software de alta qualidade. Existem inúmeros estudos que mostram que ele encontra bugs, e se eles se importam em fazer um bom trabalho, isso deve ser o suficiente para eles.

Se você está tentando convencer a administração, provavelmente terá que fazer algum tipo de raciocínio de custo/benefício dizendo que o custo dos defeitos que não serão detectados é maior do que o custo de escrever os testes. Certifique-se de incluir também custos intangíveis, como perda de confiança do cliente, etc.

0
Craig H

Isso é muito .Net-centric, mas alguém tentou Pex?

Eu estava extremamente cético até que tentei - e uau, que performance. Antes eu pensava "Eu não vou ser convencido por este conceito até que eu entenda o que é realmente fazendo me beneficiar". Demorou uma única corrida para eu mudar de idéia e dizer "eu não se importa como você sabe que há o risco de uma exceção fatal lá, mas lá é e agora eu sei que tenho que lidar com isso "

Talvez a única desvantagem desse comportamento seja o fato de que ele irá sinalizar tudo e fornecer um backlog de seis meses. Mas, se você tivesse dívidas com código, você sempre tinha dívidas de código, você simplesmente não sabia disso. Dizer um PM há um potencial duzentos mil pontos de falha quando antes você estava ciente de algumas dúzias é uma perspectiva desagradável, o que significa que é vital que o conceito seja explicado primeiro

0
Tom W