Un nuovo nome per i test unitari [chiuso]

Non mi è mai piaciuto test unitari. 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 dai test.

Ora adoro i test unitari perché mi permettono di scrivere codice utile, che abbastanza spesso funziona per la prima volta! (toccando ferro)

Ho scoperto che le persone sono riluttanti a fare unit test o ad avviare un progetto con sviluppo test driven se si trovano in tempi rigorosi o in un ambiente in cui gli altri non lo fanno, quindi non lo fanno. Un po 'come, un rifiuto culturale di provare anche.

Penso che una delle cose più potenti del test unitario sia la fiducia che ti dà per intraprendere il refactoring. Dà anche nuova speranza trovata, che posso dare il mio codice a qualcun altro per refactoring / miglioramento, e se i miei test unitari continuano a funzionare, posso usare la nuova versione della libreria che hanno modificato, praticamente, senza paura.

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

Sono in crisi o qualcun altro vede questo rifiuto di fare test e pensa che sia un motivo simile per cui non vuole farlo?
Quali motivi fornisci tu / altri per non eseguire i test?
Quali pensi siano le loro motivazioni nel non test unitario?

E come nuovo nome per i test unitari che potrebbero superare alcune delle obiezioni, che ne dici di jContract? (Un po 'incentrato su Java che conosco :) o Contratti unitari?

Sono in crisi o qualcun altro vede questo rifiuto di fare test e pensa che sia un motivo simile per cui non vuole farlo?

La parola test nei test unitari fa pensare alle persone che si tratti di test di integrazione o test dell'interfaccia utente perché è l'unico tipo di test che abbiano mai fatto. È come mettere java in javascript.

Quando qualcosa ha un brutto nome e influisce sul modo in cui la gente ci pensa, si chiama errore di inquadratura. Gli errori di inquadratura tendono ad essere superficiali: le persone sono intelligenti e possono vedere attraverso tutti i tipi di cattivi nomi, cattive metafore.

Quali motivi fornisci tu / altri per non eseguire i test?

Dipendenze difficili da deridere / fingere /

Quali pensi siano le loro motivazioni nel non test unitario?

Il test unitario ha un conteggio dei concetti modesto e una quantità non banale di lavoro deve essere fatto prima che uno smetta di scrivere test unitari sbagliati e inizi a scriverne di buoni. Man mano che le persone migliorano nello spiegare cosa sono i 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 questo modo. Inizialmente ho usato i framework di unit test come modo conveniente per scrivere test di integrazione.

Il concetto di cambio di nome è già stato profilato. Si chiama Behavior Driven Development . I ragazzi che hanno escogitato questo hanno notato gran parte degli stessi argomenti più l'adattamento innaturale per testare qualcosa che non è stato ancora creato. Invece, il loro concetto è quello di scrivere una specifica eseguibile (che è comunque ciò di cui parla TDD).

Ho notato lo stesso respingimento. Ho anche notato che un certo numero di persone non sa come scrivere unit test. Mancano nelle discipline del processo scientifico e usano semplicemente il framework di unit test per collegare tutto e avviare il debugger. In breve, non stanno davvero migliorando l'uso del loro tempo. Non posso dirvi quanti test unitari ho visto che erano lunghi diverse decine di righe (oltre 30 righe) e non una dichiarazione di asserzione. Quando lo vedo, so che è tempo di lavorare con lo sviluppatore e insegnare loro cos'è un'asserzione e come scrivere test unitari che effettivamente testano.

I contratti sono chiamati "interfacce" nella maggior parte dei casi qui. Avere test unitari non garantisce i contratti di per sé, poiché puoi anche cambiare i test, quindi non sai effettivamente che puoi usare la nuova versione della libreria solo perché la libreria è stata testata. Devi testare anche il codice che utilizza la libreria. Questo non è diverso da qualsiasi altro test unitario, quindi non vedo perché questo avrebbe bisogno di un nuovo nome.

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

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

È perché non ne ho bisogno. Sono un appassionato di vecchia scuola, quando ero un ragazzo non avevamo fantasiosi debugger integrati con modifica e continua a scrivere codice e una compilazione potrebbe richiedere parecchio tempo, quindi abbiamo dovuto prendere le cose giusto, proprio dall'inizio. Dato tale addestramento, non vedo davvero che scrivere un carico di test unitari mi renderebbe più produttivo o il mio codice più privo di bug.

Collaudo 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 più grossolani.

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