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

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

Esta não é uma pergunta "qual é o caminho certo para o teste de unidade". Eu simplesmente quero conhecer pequenos truques pessoais que reduzem o tédio (ouso dizer) de escrever testes de unidade.

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

Acho que existem duas maneiras de testar a unidade para mim que realmente a tornam agradável:

1. Ao usar o Test Driven Development (TDD) - escrever os testes primeiro me permite pensar na próxima parte da funcionalidade ou comportamento que eu preciso no meu código. Acho que dirigir em direção ao meu objetivo final em pequenos passos e ver progressos tangíveis em direção a esse objetivo a cada poucos minutos são extremamente gratificantes e agradáveis.
2. Quando há erros, em vez de ir direto para o depurador, é um desafio divertido descobrir uma maneira de escrever um teste de unidade com falha que reproduz o erro. É extremamente satisfatório finalmente descobrir as circunstâncias que fazem o 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).

Superioridade presunçosa.

Estou apenas brincando. "Olhe para mim, cultivando bons hábitos de programação! Esse material de 'teste de unidade' nunca foi feito por mim de dez anos atrás - que idiota! E pense em todos os bugs que vou pegar como resultado de esse trabalho chato e tedioso que estou fazendo agora - meu código será incrível! Receberei um aumento com certeza! * "

* - Não, não vou.

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

Por um lado, eu quase nunca sento 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 maneira de responder "esse código faz a tarefa básica que deveria".

Por exemplo, algumas pessoas escrevem uma função e, em seguida, abrem 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 garantir que ainda funcione:

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

Como você pode ver, você continua repetindo os mesmos testes ... e precisa comparar os resultados visualmente. O teste de unidade é uma maneira de evitar a repetição neste caso; reduz quanto trabalho 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 testar manualmente. O que isso significa, é claro, é que as pessoas simplesmente não testam os componentes individuais; eles apenas testam o programa inteiro. Mas então surgem erros, e eles são muito mais difíceis de encontrar. Ou ocorrem erros e são corrigidos, mas alguém introduz o mesmo erro novamente, porque ninguém adicionou um caso de teste para garantir que isso não acontecesse. Ou alguém analisa um grande pedaço de código e diz: "Não faço ideia do que isso deve fazer, pois não está documentado e não possui testes ... se eu corrigir esse bug, não faço ideia se vou quebrar outra coisa dependendo dele; talvez eu apenas reescreva isso 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 resultante 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ódigos para entender o quão importante o teste de unidade pode ser; se todo o código deles for algo que eles escrevem uma vez e jogam fora, eles nunca o entenderão.

E os testes de unidade não devem ser escritos após o fato, como uma tarefa extra depois que você tiver um código que "sabe" que já funciona. Os testes de unidade devem ser escritos primeiro ou, no mínimo (desde que você às vezes se esqueça de escrevê-los primeiro) logo após escrever o código em questão. Isso se chama desenvolvimento orientado a teste e pode ajudar a melhorar suas APIs; se você escrever os testes que exercitam as APIs primeiro, aprenderá onde as APIs são difíceis de usar antes de escrever o código e poderá reprojetar muito mais facilmente do que se você apenas adicionasse os testes posteriormente.

Eu não sei. O que definitivamente torna o teste de unidade mais agradável para mim é o pensamento de toda a depuração frustrante, demorada, chata e sem recompensa que não passarei toda vez que fizer uma alteração no software :)

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

Obviamente, há a satisfação do desenvolvimento do primeiro teste e a sensação que você tem quando o design e os testes se juntam. No entanto, escrever testes para código pré-existente / legado pode ser entorpecedor 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 um pouco de concorrência com você e / ou outras pessoas para aumentar os números de cobertura. Concedido, você pode ir longe demais e criar alguns testes ruins, mas pode ser um bom motivador.

Tente entrar no fluxo . Defina metas difíceis, mas alcançáveis ​​para si mesmo. Qual poderia ser um objetivo no teste de unidade? Por exemplo, tente escrever mais rapidamente, mantendo a qualidade. Os testes de unidade não requerem muita reflexão, portanto é improvável que haja erros. Concentre-se em seu objetivo e verifique com frequência para ver como está se aproximando.

Às vezes, para me motivar, anotarei minha "cobertura de código" atual no início do dia. Então, cada vez que escrevo um teste e o passo a passo é executado, vou executar o pacote e atualizar o número da cobertura. É divertido e ajuda a me lembrar por que estou fazendo isso. (Existem outras razões também, mas eu gosto dos números. Talvez seja apenas eu!)

Ao não tentar me iludir, posso enganar minha mente, pensando 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 bastante, fazendo-me perceber que estou procurando 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 aborrecida e esmagadora de alma, pergunto-me se posso me dar ao luxo de abandoná-lo, ou seja, não ter altas garantias sobre correção funcional.

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

Ao aceitar meu destino, continuo empurrando esses objetos quadrados com letras, números e símbolos na frente de mim, que chamamos de teclado, sabendo por experiência em primeira mão que com cada clique no teclado, o final do teste de unidade está mais próximo do que ele tem sempre sido.