Quali tecniche possono essere utilizzate per rendere più interessanti i test di scrittura?

Question

Devo ammettere che spesso mi sforzo di praticare lo sviluppo guidato dai test. Nonostante l'utilizzo di Ruby on Rails che rende TDD super facile perché è cotto, trovo che i test di scrittura siano così noiosi! È come un filo interdentale dentale; So che dovrei farlo, ma fatico a raccogliere molto entusiasmo.

• Quali tecniche si usa per fare i test di scrittura interessante? Ad esempio, un suggerimento che ho visto è stato inventare una piccola storia intorno ai dati delle apparecchiature di prova piuttosto che usare solo dati privi di significato e non correlati.

Answer 1

Se si scrivono prima i test, sono le specifiche per la codifica.

Tutto il pensiero deve essere fatto durante la scrittura dei test. "Cosa deve fare ?" "Come faccio a sapere che è fatto?" "Quali interfacce ha bisogno di essere deriso?"

Inoltre, se si strutturano i test utilizzando una semplice convenzione di denominazione (utilizzando "shoulds") è possibile determinare più facilmente cosa si suppone stia accadendo.

Vedere http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx per alcuni pensieri su questo.

Se si scrivono i test per ultimi, sono noiosi, dal momento che si dice il codice funziona.

Answer 2

Se sei annoiato durante la scrittura dei test, stai testando le cose sbagliate. Sto scrivendo dei test quando qualcosa è fallito, quando non ho capito qualcosa o quando qualcosa di nuovo viene fuori. In questo modo, i miei test non sono mai futili o conformi a una politica di "copertura del codice al 100%" e non mi annoio mai.

Answer 3

Scrivere test negativi di solito è più interessante di quelli del "giorno di sole". Pensa attraverso tutti i modi inventivi in ​​cui potresti rompere la tua classe (passando in null, valori troppo grandi/piccoli ecc.).

Non solo si darà il vostro cervello un angolo diverso da masticare sarà anche rendere la vostra classe più robusto in quanto le persone saranno chiamarla con nulli, grandi numeri ecc ecc

Answer 4

Prima voglio scrivere codice di produzione, quindi mi sforzo di scrivere prima il test: né scrivere alcuna riga di codice senza un test fallito. Questo non è sempre possibile, ma almeno mi costringe a scrivere dei test.

poi cerco di rompere il codice che ho scritto usando i test di confine, i casi negativi, l'uso di API sbagliata (per esempio mancanti o diverse chiamate di inizializzazione) ...

Inoltre ho eseguito il test spesso; il messaggio "tutti i test passati" alla fine mi fa sentire a mio agio su ciò che è stato scritto finora ... e sono anche felice quando ho trovato (e corretto) un bug.

A volte, mi sto divertendo con i nomi e i numeri che sto usando per i miei test (data di nascita, numero del giocatore preferito, numeri di telefono ...).

Answer 5

Se si utilizza TDD correttamente, è necessario scrivere il test prima di scrivere il codice. Dovrebbe essere un buon test per garantire che il codice che stai scrivendo funzioni e dovrebbe essere un piccolo incremento.

Come tale, è davvero parte dello sviluppo. Cosa c'è di diverso dalla scrittura di un test unitario rispetto alla scrittura di una funzione che è necessario implementare il codice?

Dicendo che si trovano test di scrittura noiosi, è come dire "Trovo noioso scrivere I/O .. c'è qualcosa che posso fare per renderlo più interessante?" o "Trovo noioso scrivere UI .."

Beh, in realtà scrivere qualsiasi tipo di codice può essere noioso, o interessante ... ma è più una funzione dello sviluppatore che del codice :) Il mio amico è costretto scrivere codice per un'azienda, anche se non è un vero programmatore, e il suo commento è "Non vedo come puoi farlo tutto il giorno !!!"

Dato che sei uno sviluppatore, la mia sensazione è che ti piace scrivere codice, quindi il vero problema è che non stai seguendo correttamente TDD e fare test è una parte reale del tuo sviluppo. Anche se un framework può tentare di renderlo necessario, è davvero a te seguire correttamente il processo (cioè scrivere prima il test) e integrarlo veramente con il tuo sviluppo.

Quindi, è davvero una parte insignificante dello sviluppo generale, come il controllo del codice, il commento, la formattazione, che alcune persone potrebbero trovare "noiose" ma sono necessarie. Non ci disturba perché è solo una parte dello sviluppo e troviamo lo sviluppo interessante.

Answer 6

Sono preoccupato che questo suoni come un odore di codice.

I test sono noiosi perché sono molto ripetitivi?

I test coprono le stesse cose più volte? (cioè i test case non testano solo una cosa alla volta, quindi ci sono molti test ripetuti delle stesse cose ...?)

Potresti annoiarti perché i test sono scritti al livello sbagliato di astrazione o ti costringono a fare un sacco di lavoro che non è necessario.

Sembra che qualcosa debba essere refactored o almeno astratto in modo che ogni test esprima solo ciò che è nuovo o diverso dal resto del codice.

Se molti test sembrano ovvi o noiosi, mancano alcune delle astrazioni che si stanno utilizzando.

avrei iniziare la ricerca di modelli nei tipi di test che si sentono sono noiosi o noioso e vedere se qualcosa non può essere fatto - come la creazione di un framework di test molto piccolo per contribuire a rendere i test più facile da scrivere.

All'esame, potrebbe essere solo necessario eliminare alcuni test ridondanti e pulire la denominazione, in modo che sia chiaro esattamente ciò che è necessario testare e cosa si può fare affidandosi al test in un'altra parte della suite di test.

Questo è tutto sui trade-off. Penso che valga la pena rivalutare il tipo di test che stai scrivendo e dare un'occhiata a quali alternative potrebbero esserci.

Answer 7

C'è da considerare che la noia non è affatto male. Direi che è più forte rispetto al tuo codice normale rispetto al tuo codice di test, ma probabilmente vale anche per i test.

L'eccitazione arriva quando non sai cosa sta facendo il tuo codice, quando non ti fidi di esso, quando ogni volta che lo esegui - o lo rilasci - c'è quel piccolo ragazzo seduto sulla tua spalla che strilla "No!" . Quando passi molto tempo nel debugger; quando il tuo codice è troppo complesso, intricato e nodoso (non in senso buono) e spaventoso.

La noia può essere l'opposto dell'eccitazione, e vista in quella luce, noioso è buono. Un passo dopo l'altro, passo prevedibile dopo il passo prevedibile, scriviamo un codice di lavoro semplice e affidabile. Rosso-verde-refactoring.

Un codice di lavoro semplice e affidabile è qualcosa di cui posso essere entusiasta.