Come hai reso i test di unità più divertenti?

In primo luogo, sono d'accordo con te: se stai scrivendo i tuoi test unitari su codice già completato, o stai testando manualmente il tuo codice, trovo che sia estremamente noioso anche.

Trovo che ci siano due modi per testare le unità che lo rendono davvero divertente:

1. Usando Test Driven Development (TDD) - scrivere i test prima mi consente di pensare alla prossima funzionalità o comportamento che ho bisogno nel mio codice. Trovo che guidare verso il mio obiettivo finale a piccoli passi e vedere progressi tangibili verso quell'obiettivo ogni pochi minuti estremamente gratificante e divertente.
2. Quando ci sono dei bug, piuttosto che andare direttamente al debugger, è una sfida divertente scoprire un modo per scrivere un test unitario in errore che riproduca il bug. È estremamente soddisfacente capire finalmente le circostanze che fanno fallire il tuo codice, quindi aggiustarlo e vedere la barra diventare verde per il nuovo test fallito (e rimanere verde per tutti i test esistenti).

Superiorità compiaciuta.

Sto solo scherzando. "Guardami, coltivando buone abitudini di programmazione! Questo 'test di unità' è qualcosa di Me From Ten Years Ago non avrebbe mai fatto - che pazzo! E pensi solo a tutti i bug che catturerò come risultato di questo lavoro noioso e noioso che sto facendo in questo momento - il mio codice sarà fantastico! Avrò sicuramente un aumento! * "

* - No, non lo farò.

Trovo che sia come allenarsi o mangiare sano; fino a quando i benefici tangibili non entrano in gioco ("palle sante, sto davvero prendendo uno schifo di errori di regressione che sarebbero entrati in produzione!"), l'orgoglio morale di sapere che stai facendo The Right Thing può aiutarti a portarti attraverso.

Non lo so. Ciò che rende decisamente più divertente il test unitario è il pensiero di tutte le debugging frustranti, lunghe, noiose e poco gratificanti che non avrò mai sperimentato ogni volta che apporto un cambiamento nel software:)

Per prima cosa, non mi limito quasi mai a sedermi e a scrivere test di unità. I test unitari sono un mezzo per un fine, non un fine a se stessi. Sono un modo per rispondere "questo codice fa il compito di base che si suppone."

Ad esempio, alcune persone scriveranno una funzione, quindi apriranno una sessione interattiva per testarla su alcuni valori e assicurarsi che funzioni:

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

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

Ma ora scopri un bug:

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

Quindi lo aggiusti:

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

Ma ora dovresti testare per assicurarti che funzioni ancora:

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

Come puoi vedere, continui a ripetere gli stessi test ... e devi confrontare i risultati visivamente. Il test unitario è un modo per evitare la ripetizione in questo caso; riduce il lavoro che devi fare. E mentre questo è un piccolo esempio stupido, nel mondo reale diventa sempre più importante e sempre più difficile da testare manualmente. Ciò significa, ovviamente, che le persone semplicemente non testano i singoli componenti; testano solo l'intero programma. Ma poi spuntano gli errori, e sono molto più difficili da trovare. O gli errori si verificano, e sono corretti, ma qualcuno introduce di nuovo lo stesso bug, perché nessuno ha aggiunto un caso di test per assicurarsi che ciò non accadesse. O qualcuno guarda un grande pezzo di codice e dice "Non ho idea di cosa dovrebbe fare, dal momento che non è documentato e non ha test ... se risolvo questo bug, non ho idea se romperò qualcos'altro a seconda, forse lo riscriverò da capo. "

I test unitari riducono tutto il lavoro extra in questi casi. Il modo migliore per renderli divertenti è assicurarsi che le persone capiscano tutto il lavoro che stanno sostituendo e la flessibilità extra derivante dalla conoscenza di ciò che ogni pezzo di codice dovrebbe fare. In una certa misura, le persone hanno bisogno di avere un po 'più di esperienza con la scrittura e di mantenere un ampio codice di base per capire quanto sia importante il test unitario; se tutto il loro codice è qualcosa che scrivono una volta e buttano via, non lo capiranno mai.

E i test unitari non dovrebbero essere scritti dopo il fatto, come un lavoro extra una volta che hai il codice che "sai" già funziona. I test unitari dovrebbero essere scritti prima, o per lo meno (dato che a volte si dimentica di scriverli prima) subito dopo aver scritto il codice in questione. Questo è chiamato sviluppo basato su test e può aiutare a migliorare le API; se scrivi i test che eseguono prima le API, imparerai dove le API sono difficili da usare prima ancora di scrivere il codice, e puoi riprogettare molto più facilmente rispetto a quando aggiungerai i test solo in seguito.

Ovviamente, vi è la soddisfazione dello sviluppo del test-first e della sensazione che si prova quando il design e i test si incontrano. Tuttavia, scrivere test per codice preesistente / legacy può essere sconvolgente e frustrante. Quando il nostro progetto era in un modello di manutenzione, ho scritto test per codice non testato utilizzando il report di copertura come gioco. Puoi creare un po 'di competizione con te stesso e / o altri per aumentare i numeri di copertura. Certo, potresti prenderlo troppo lontano e creare alcuni test non validi, ma può essere un buon motivatore.

La compiaciuta superiorità che provi quando controlli il codice che è solido, solido e stabile. E se scrivi test unitari con uno strumento di copertura del codice, puoi vantare nei tuoi commenti di controllo che la copertura del tuo codice è del 90% o superiore.

Prova ad entrare nel Flusso . Stabilisci obiettivi duri ma realizzabili per te stesso. Quale potrebbe essere un obiettivo nei test unitari? Ad esempio, prova a scrivere più velocemente mantenendo la qualità. I test unitari non richiedono troppi pensieri, quindi è improbabile che sbagliare. Concentrati sul tuo obiettivo e controlla spesso per vedere come ti stai avvicinando.

A volte per essere motivato, scriverò la mia attuale "copertura del codice" all'inizio della giornata. Quindi ogni volta che scrivo un test e lo faccio passare, eseguirò la suite e aggiornerò il numero di copertura. È divertente e mi aiuta a ricordarmi perché lo sto facendo. (Ci sono anche altri motivi, ma mi piacciono i numeri. Forse sono solo io!)