ti-enxame.com

Como você tornou o teste de unidade mais agradável?

Se você sempre gostou de testes de unidade, bom para você! Mas para os desafortunados que não nasceram com gosto por isso, como você conseguiu tornar esta tarefa mais agradável?

Esta não é uma pergunta "qual é a maneira certa de fazer um teste de unidade". Eu simplesmente quero saber pequenos truques pessoais que reduzem o tédio (ouso dizer) de escrever testes de unidade.

18
Preets

Em primeiro lugar, concordo com você - se você está escrevendo seus testes de unidade em código já concluído, ou está testando manualmente a unidade de seu código, também acho isso extremamente chato.

Acho que existem duas formas de teste de unidade para mim que realmente o tornam agradável:

  1. Usando o Test Driven Development (TDD) - escrever os testes primeiro me permite pensar sobre a próxima parte da funcionalidade ou comportamento de que preciso em meu código. Acho que dirigir em direção ao meu objetivo final em pequenos passos e ver um progresso tangível em direção a esse objetivo a cada poucos minutos é extremamente gratificante e agradável.
  2. Quando há bugs, em vez de ir direto para o depurador, é um desafio divertido descobrir uma maneira de escrever um teste de unidade com falha que reproduza o bug. É extremamente satisfatório finalmente descobrir as circunstâncias que fazem seu código falhar, corrigi-lo e observar a barra ficar verde para o novo teste com falha (e permanecer verde para todos os testes existentes).
22
Paddyslacker

Superioridade presunçosa.

Estou apenas meio brincando. "Olhe para mim, cultivando bons hábitos de programação! Esse negócio de 'teste de unidade' é algo que eu, de dez anos atrás, nunca teria feito - que idiota! E pense em todos os bugs que irei detectar como resultado de este trabalho enfadonho e tedioso que estou fazendo agora - meu código será incrível! Vou ganhar um aumento com certeza! * "

* - Não vou.

Acho que é como malhar ou comer de forma saudável; até que os benefícios tangíveis realmente apareçam ("Caramba, estou realmente pegando uma tonelada de erros de regressão que teriam entrado na produção!"), o orgulho moral de saber que você está fazendo a coisa certa pode ajudar a carregá-lo através.

12
BlairHippo

Por um lado, quase nunca fico sentado e escrevo testes de unidade. Os testes de unidade são um meio para um fim, não um fim em si mesmos. Eles são uma forma de responder "este código cumpre a tarefa básica que deveria".

Por exemplo, algumas pessoas escreverão uma função e, em seguida, abrirão uma sessão interativa para testá-la em alguns valores e verificar se está funcionando:

def fact x
  if x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact 10
=> 3628800
>> fact 7
=> 5040

Mas agora você descobre um bug:

>> fact -1
SystemStackError: stack level too deep
    from (irb):2:in `fact'
    from (irb):5:in `fact'
    from (irb):10

Então você conserta:

def fact x
  if x < 0
    raise "Can't take the factorial of a negative number"
  elsif x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact -1
RuntimeError: Can't take the factorial of a negative number
    from (irb):3:in `fact'
    from (irb):10

Mas agora você realmente deve testar para ter certeza de que ainda funciona:

>> fact 10
=> 3628800
>> fact 7
=> 5040

Como você pode ver, você fica repetindo os mesmos testes ... e você tem que comparar os resultados visualmente. O teste de unidade é uma forma de evitar a repetição neste caso; reduz a quantidade de trabalho que você precisa fazer. E embora este seja um pequeno exemplo bobo, no mundo real, torna-se cada vez mais importante e cada vez mais difícil de testar manualmente. O que isso significa, é claro, é que as pessoas simplesmente não testam os componentes individuais; eles apenas testam todo o programa. Mas então os insetos aparecem e são muito mais difíceis de encontrar. Ou bugs acontecem e são corrigidos, mas alguém introduz o mesmo bug novamente, porque ninguém adicionou um caso de teste para ter certeza de que isso não aconteceu. Ou alguém olha para um grande pedaço de código e diz "Não tenho ideia do que isso deve fazer, uma vez que não está documentado e não tem testes ... se eu corrigir esse bug, não tenho ideia se vou quebrar outra coisa, dependendo disso; talvez eu apenas reescreva do zero. "

Os testes de unidade reduzem todo o trabalho extra nesses casos. A melhor maneira de torná-los divertidos é garantir que as pessoas entendam todo o trabalho que estão substituindo e a flexibilidade extra que advém de saber o que cada parte do código deve fazer. Até certo ponto, as pessoas precisam ter um pouco mais de experiência em escrever e manter uma grande base de código para entender como o teste de unidade pode ser importante; se todo o código é algo que eles escrevem uma vez e jogam fora, eles nunca entenderão.

E os testes de unidade não devem ser escritos após o fato, como uma tarefa extra, uma vez que você tem um código que "sabe" que já funciona. Os testes de unidade devem ser escritos primeiro, ou pelo menos (já que você às vezes se esquece de escrevê-los primeiro) logo após escrever o código em questão. Isso é chamado de desenvolvimento orientado a testes e pode ajudar a tornar suas APIs melhores; se você escrever os testes que exercitam as APIs primeiro, aprenderá onde as APIs são difíceis de usar antes mesmo de escrever o código e pode redesenhar muito mais facilmente do que se você apenas adicionar os testes depois.

7
Brian Campbell

Eu não sei. O que definitivamente torna o teste de unidade mais agradável para mim é a ideia de todas as depurações frustrantes, demoradas, enfadonhas e ingratas que não terei de fazer toda vez que faço uma alteração no software :)

5
back2dos

Obviamente, existe a satisfação do desenvolvimento test-first e a sensação que você tem quando o design e os testes se juntam. No entanto, escrever testes para código preexistente/legado pode ser entorpecente e frustrante. Quando nosso projeto estava em um padrão de manutenção, escrevi testes para código não testado usando o relatório de cobertura como um jogo. Você pode criar uma pequena competição consigo mesmo e/ou outras pessoas para aumentar os números de cobertura. É verdade que você pode ir longe demais e criar alguns testes ruins, mas pode ser um bom motivador.

3
Matt H

A superioridade presunçosa que você sente quando faz check-in de um código que é sólido, robusto e estável. E se você escrever testes de unidade com uma ferramenta de cobertura de código, poderá se gabar em seus comentários de verificação de que sua cobertura de código é de 90% ou mais.

3
C Johnson

Tente entrar no Fluxo . Estabeleça metas difíceis, mas alcançáveis ​​para você mesmo. Qual poderia ser uma meta em testes de unidade? Por exemplo, tente escrever mais rápido mantendo a qualidade. Os testes de unidade não exigem muita reflexão, portanto, é improvável que se engane. Concentre-se em seu objetivo e verifique com frequência para ver quando você está se aproximando dele.

1
Tamás Szelei

Não tentando me iludir, posso enganar minha mente fazendo-a pensar que o teste de unidade pode ser agradável por qualquer período sustentável de tempo.

Aceitar a realidade de que o teste de unidade não existe para ser apreciado me ajuda muito, fazendo-me perceber que estou procurando por algo em um lugar onde nunca deveria estar.

Nessas breves excursões mentais, quando chego ao ponto de perceber que o teste de unidade é o que realmente é, ou seja, uma tarefa cruel, insuportavelmente chata e de esmagar a alma, me pergunto se posso me dar ao luxo de deixá-los ir, ou seja, não ter altas garantias sobre correção funcional.

Invariavelmente, a resposta é um sonoro "não".

Ao aceitar meu destino, continuo empurrando esses objetos quadrados com letras, números e símbolos na minha frente, que chamamos de teclado, sabendo por experiência própria que a cada clique do teclado, o fim do teste de unidade está mais perto do que isso sempre foi.

0
bugfoot

Às vezes, para me motivar, escrevo minha "cobertura de código" atual no início do dia. Então, cada vez que escrevo um teste e faço com que ele seja aprovado, executarei o pacote e atualizarei o número de cobertura. É divertido e me ajuda a lembrar por que estou fazendo isso. (Existem outros motivos também, mas gosto dos números. Talvez seja só eu!)

0
Marcie