Un nuovo nome per i test unitari [chiuso]

Question

Un nuovo nome per i test unitari [chiuso]

#1 da (5 voti)
#2 da (3 voti)
#3 da (0 voti)
#4 da (-1 voti)

8

Non mi è mai piaciuto il test delle unità. Ho sempre pensato che aumentasse la quantità di lavoro che dovevo fare.
Risulta, questo è vero solo in termini di numero effettivo di righe di codice che scrivi e inoltre, questo è completamente compensato dall'aumento del numero di righe di codice utile che puoi scrivere in un'ora con test e sviluppo guidato da test.

Ora amo i test unitari in quanto mi permettono di scrivere codice utile, che spesso funziona prima volta! (bussa sul legno)

Ho scoperto che le persone sono riluttanti a fare test unitari o avviare un progetto con sviluppo guidato dai test se sono sottoposti a rigide tempistiche o in un ambiente in cui altri non lo fanno, quindi non lo fanno. Un po 'come, un rifiuto culturale di provare anche.

Penso che una delle cose più potenti riguardo ai test unitari sia la sicurezza che ti dà di intraprendere il refactoring. Dà anche una nuova speranza, che posso dare il mio codice a qualcun altro per refactoring / migliorare, e se i miei test di unità funzionano ancora, posso usare la nuova versione della libreria che hanno modificato, praticamente, senza paura.

È questo l'ultimo aspetto dei test unitari che penso abbia bisogno di un nuovo nome. Il test unitario è più simile a un contratto di ciò che questo codice dovrebbe fare ora e in futuro.
Quando ascolto la parola test, penso ai topi in gabbia, con più esperimenti su di loro per vedere l'efficacia di un composto. Questo non è il test unitario, non stiamo provando un codice diverso per vedere quale sia l'approccio più affettivo, stiamo definendo quali output ci aspettiamo con quali input. Nell'esempio dei topi, i test unitari sono più come le definizioni di come l'universo funzionerà rispetto agli esperimenti fatti sui topi.

Sono in crisi o qualcun altro vede questo rifiuto di fare test e pensano che sia un motivo simile per cui non vogliono farlo?
Quali sono le ragioni che voi / altri danno per non provare?
Cosa pensi che le loro motivazioni non siano nel test unitario?

E come nuovo nome per le unit test che potrebbero superare alcune obiezioni, che ne dici di jContract? (Un po 'di Java centrico che conosco :), o Contratti di Unità?

tdd unit-testing

posta Will 03.01.2011 - 18:20

fonte

4 risposte

Leggi altre domande sui tag tdd unit-testing

Valutare se scrivere test di unità o di integrazione prima su progetti blue-sky / prototype Crittografia / protezione dei dati - dove trovare informazioni sulle migliori pratiche di alto livello [chiuso]

score 5 · Answer 1

Am I on crack or does anyone else see this refusal to do testing and do they think it's a similar reason they don't want to do it?

La parola testing in unit test fa pensare che si tratti di test di integrazione o di test dell'interfaccia utente, questo è l'unico tipo di test che abbiano mai fatto. È come mettere java in javascript.

Quando qualcosa ha un brutto nome e influisce sul modo di pensare della gente, si chiama errore di framing. Gli errori di frame tendono ad essere superficiali: le persone sono intelligenti e possono vedere attraverso tutti i tipi di brutti nomi, cattive metafore.

What reasons do you / others give for not testing?

Dipendenze difficili da simulare / false /

What do you think their motivations are in not unit testing?

Il test unitario ha un modesto concetto di conteggio e una quantità non banale di lavoro deve essere fatta prima che uno smetta di scrivere test di unità cattivi e inizi a scrivere quelli buoni. Man mano che le persone migliorano la spiegazione dei test unitari, l'adozione aumenterà. Nella mia esperienza, i test unitari hanno un effetto quasi magico sulla produttività e sulla qualità del codice. Ma non è iniziato in quel modo. Inizialmente ho utilizzato i framework di test delle unità come metodo pratico per scrivere test di integrazione.

score 3 · Answer 2

Il concetto di cambio di nome è già stato proferito. Si chiama Sviluppo guidato dal comportamento . I ragazzi che sono venuti fuori hanno notato molti degli stessi argomenti oltre alla misura innaturale per testare qualcosa che non è ancora stato creato. Invece, il loro concetto è quello di scrivere una specifica eseguibile (che è ciò che TDD è in realtà circa).

Ho notato lo stesso pushback. Ho anche notato che un certo numero di persone semplicemente non sa come scrivere test unitari. Sono carenti nelle discipline del processo scientifico e usano semplicemente il quadro di test unitario come un modo per collegare tutto insieme e avviare il debugger. In breve, non stanno veramente migliorando l'uso del loro tempo. Non posso dirvi quanti test unitari ho visto che erano diverse decine di righe (30+ linee) e non una dichiarazione di affermazione. Quando lo vedo, so che è il momento di lavorare con lo sviluppatore e insegnare loro che cosa è un'asserzione, e come scrivere test unitari che effettivamente testano.

score 0 · Answer 3

I contratti sono chiamati "interfacce" nella maggior parte dei casi qui. Avere test unitari non garantisce i contratti di per sé, in quanto è possibile modificare anche i test, in modo da non sapere in realtà che è possibile utilizzare la nuova versione della libreria solo perché la libreria è stata testata. È necessario testare il codice che utilizza anche la libreria. Non è diverso da altri test di unità, quindi non vedo perché avrebbe bisogno di un nuovo nome.

Penso, come te, che la maggior parte delle persone riluttanti a fare test lo faccia perché pensano che sia più lavoro e inutile.

score -1 · Answer 4

Ti dirò perché non mi piace TDD: non perché non riesco a vedere il valore in esso, o riconoscere i benefici di una suite di test che posso eseguire per verificare tutto il mio codice dopo ogni modifica.

È perché non ne ho bisogno. Sono un dev della vecchia scuola, quando ero un ragazzino non avevamo nessun debugger integrato di fantasia con edit-and-continuate a scrivere il codice, e una compilazione poteva richiedere molto tempo quindi dovevamo fare le cose giusto, sin dall'inizio. Dato un addestramento del genere, non vedo davvero che scrivere un carico di test unitari mi renderebbe più produttivo o il mio codice più privo di bug.

Esamino il mio codice, ma come ho sempre fatto, questo è stato sull'intera cosa piuttosto che sui singoli pezzi. Quindi forse ho dei "test unitari", ma sono piuttosto a grana grossa.

Quindi questa è la mia ragione. Non riesco a vedere la necessità che io lo faccia. Il codice che produco è abbastanza buono e, in tal caso, perché dovrei cambiare i miei processi per correggere qualcosa che non è rotto?