unit-testing - unidade - unit test c#




O teste de unidade vale o esforço? (20)

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 adicionássemos funcionalidade ou corrigimos bugs. Infelizmente, nossa base de código não se presta a testes fáceis.


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, acho que muitas vezes a melhor maneira de convencer alguém de alguma coisa é ouvir 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 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ê terminará 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.

Os testes de unidade são uma ferramenta, como qualquer outra, e devem ser aplicados de 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 do 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 deixar de escrever 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 precisam ser repetidas toda vez que o código de produção muda, enquanto testes de unidade 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 levar 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 o esforço se, mesmo uma vez, ocorrerem problemas que podem 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 timestamp 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 os testes de unidade não são uma bala de prata e há uma coisa como muito teste de unidade. 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 alteração 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.


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 .


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.


Em suma - sim. Eles valem cada centavo 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


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.


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


Eu não vi isso em nenhuma das outras respostas, mas uma coisa que 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.


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 o seu teste.

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


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:

  • O 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ódigos executáveis para outros membros da equipe (e para você em seis meses)
  • refatoração impiedosa - isso é incrivelmente recompensador, experimente!

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.


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.


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.

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?


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 de ú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 :)


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.


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. No TDD você está apostando nas chances de ambos serem ruins / com bugs baixos. Muitas vezes é o teste que precisa ser corrigido, 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 que o resto da minha cobertura de código esteja 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 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 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.


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.


Uma das melhores coisas sobre o teste de unidade é que seu código ficará mais fácil de ser testado à medida que você fizer isso. 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 em 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á foram pagos.

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


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 de unidade.


[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ê testar 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 você 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


O teste de unidade é 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á uma corrida inicial, o 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 começa a se aproximar. 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.

Portanto, 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 Unitário pode exigir uma enorme quantidade de esforço se você estiver lidando com código-base de espaguete em uma empresa que não valoriza realmente a qualidade do código. (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 emprego para realmente fazer o Teste de Unidade funcionar para você.





unit-testing