Ho una buona conoscenza dei test unitari. Ho cercato di leggere sui contratti di codice. Aiuta davvero i test unitari? È sovrastimato soprattutto quando parliamo di contratti in codice che aiutano a fare test unitari. Mi riferisco in particolare ai contratti in .net 4.0. Uso nunit per il test delle unità.I contratti di codice aiutano davvero i test delle unità?
Sì e No. I test unitari sono fondamentalmente un contratto che dice, MyMethod() prende X e si aspetta che Y sia un risultato, e quando non lo fa, i test unitari falliscono e tu sei avvisato come lo sviluppatore di MyMethod() che hai rotto qualcosa al suo interno I contratti di codice aiutano a scrivere test di unità, poiché i requisiti dei contratti facilitano la conoscenza dei requisiti dei test unitari quando vengono scritti. Tuttavia, il vero motivo per i contratti di codice non è per te, ma per gli altri sviluppatori che utilizzano l'API che crei. I test unitari consentono di conoscere input e output corretti, ma quando si rilascia il codice in modalità wild, i test unitari non vengono rilasciati con il dll. I contratti di codice danno agli sviluppatori altri il vantaggio di conoscere, attraverso contratti di compilazione e controllo, gli stessi requisiti. I contratti proteggono da quegli sviluppatori (io) che hanno una tendenza orribile a non leggere la documentazione del metodo e iniziano a trasmettere le cose, quindi ora saranno avvertiti attivamente attraverso i contratti.
No, non penso che i contratti di codice ti aiutino a scrivere test di unità. I test unitari definiscono il comportamento e i vincoli di una determinata azione. Una di quelle specifiche scritte nei test unitari potrebbe essere che gli argomenti di un metodo non possono essere nulli.
In tal caso, è comunque necessario scrivere il test dell'unità. Il contratto di codice è un modo per implementare le specifiche, ma non l'unico modo.
In altre parole, non dare per scontato che l'utilizzo di un contratto di codice significhi che non è necessario scrivere un test di unità! Se qualcuno cambia il contratto del codice o lo rimuove, non avrai un test che ti dice che le specifiche previste non sono riuscite.
Non credo che nessuno stesse dicendo che i contratti di codice dovrebbero sostituire i test unitari. –
Sono d'accordo che i contratti non aiutano a scrivere i test unitari. Idealmente, i test dovrebbero venire prima, quindi non dovrebbero esistere contratti fino a quando non ci sarà un test fallimentare. I contratti possono quindi essere scritti per far rispettare eventuali test negativi ("dovrebbe lanciare"). –
I contratti di codice possono essere utilizzati per le cose che non è possibile utilizzare unit test (contratti per interfacce). Sono applicati nelle catene di ereditarietà (dove puoi facilmente commettere errori con il test manuale dell'unità). Forniscono la documentazione automaticamente (cosa che i test unitari non possono fare). Possono fornire controlli di runtime in produzione (cosa che i test di unità non possono fare).
D'altra parte, i contratti falliscono solo quando vengono esercitati, e quindi senza test unitari non si ha alcuna garanzia della qualità del codice (cioè che tutto il codice riempie i vari contratti). I due concetti sono gratuiti.
Ma non duplicherò la mia logica? Voglio dire, avremo la stessa logica (pre e post condizioni) per i contratti e le prove di unità. –
Lo farà, e da un punto di vista purista, dovrebbe, dal momento che se qualcuno rimuoverà accidentalmente il contratto, i test unitari continuerebbero a verificare la logica che non si vuole che faccia qualcosa che potrebbe fare ora, o viceversa. I contratti possono essere una guida per scrivere i test unitari, ma non sono ancora un sostituto per loro. –
Trovo difficile concordare che i contratti duplicano i test unitari. I contratti di codice stabiliscono i requisiti, i test unitari verificano che siano veri. In un certo senso, i test stanno verificando che i tuoi contatti siano corretti - i contratti sono codice consegnabile e quindi dovrebbero essere testati. –