Il Test-Driven Design non è Unit Testing [chiuso]

Quello che sta descrivendo è una differenza tra i test unitari (testare un'unità in isolamento, in questo caso una classe ma puoi testare ogni metodo se sei abbastanza masochista) e test di integrazione dove test la classe e anche come funziona con altre classi. Questo non è un test unitario: non stai testando l'unità ma "molte unità".

Credo che quest'ultimo sia migliore, il problema è che è più difficile ottenere una copertura totale del codice, cioè testare ogni parte del sistema. IMHO anche se tu collaudi unitamente ogni metodo, devi comunque testare i percorsi attraverso il sistema per assicurarti che lavorino insieme. (per esempio, posso testare una presa USB e garantirne il funzionamento, testare una presa USB e dimostrare che funziona .. e poi funzioneranno perfettamente quando assemblati .. ma la mia spina è di tipo A e la mia presa è di tipo B, d'oh. Questo difetto di progettazione non dovrebbe mai essere stato lì in primo luogo, ma possiamo dire che su qualsiasi errore, ed è per questo che testiamo le cose).

Bene, perché non basta chiedere all'uomo stesso ?

Despite the variations, there are some common elements. Firstly there is a notion that unit tests are low-level, focusing on a small part of the software system. Secondly unit tests are usually written these days by the programmers themselves using their regular tools - the only difference being the use of some sort of unit testing framework. Thirdly unit tests are expected to be significantly faster than other kinds of tests.

So there's some common elements, but there are also differences. One difference is what people consider to be a unit. Object-oriented design tends to treat a class as the unit, procedural or functional approaches might consider a single function as a unit. But really it's a situational thing - the team decides what makes sense to be a unit for the purposes of their understanding of the system and its testing. Although I start with the notion of the unit being a class, I often take a bunch of closely related classes and treat them as a single unit. Rarely I might take a subset of methods in a class as a unit. However you define it doesn't really matter.

...

Isolation

A more important distinction is whether the unit you're testing should be isolated from its collaborators. ... But not all unit testers use this isolation. Indeed when xunit testing began in the 90's we made no attempt to isolate unless communicating with the collaborators was awkward ...

Sul suo blog mostra delle belle illustrazioni e spiega cosa intende in una buona profondità.

Quindi, quando ci chiediamo cosa intenda Martin Fowler e se sia ancora vero oggi, penso che Martin Fowler del 2014 sia la migliore fonte possibile.

TDD o Test-Driven Development è dove dovresti creare un test unitario fallito su un metodo, scrivere il codice del metodo in secondo luogo, quindi vedere se il test passa. In caso contrario, si refactoring il codice fino a quando non passa e quindi passare al test dell'unità successiva dello stesso metodo. Non è necessario utilizzare TDD per creare test unitari. È possibile scrivere prima il metodo e quindi creare test unitari per il secondo, assicurandosi che ogni test passi. Se stai testando una classe, esegui il test di integrazione perché può richiamare un livello dati che comunica con il database. Per evitare che sia necessario utilizzare un framework di simulazione in modo che i test possano essere automatizzati e non fare affidamento su connessioni esterne all'applicazione.

11 anni dopo lo dichiarerei in questo modo:

I test di unità in Agile sono spesso diversi dai test di unità classiche, perché in Agile di solito non si esegue il test di ciascuna unità separatamente. Stai testando ogni classe e le sue connessioni immediate con i suoi vicini.

Nota: questo è ancora distinto dal test di integrazione in cui testate il codice e le sue dipendenze e i servizi richiesti.