Il nostro progetto ha molti livelli,
Servizi di applicazione
etc ..
Stiamo solo scrivendo unit test per il livello di business logic e prendendo in giro altre parti. In questo caso è possibile e ragionevole fare TDD? (Tutte le classi di business logic consumano altre classi tramite DI con dipendenze iniettate dal costruttore)
We are only writing unit tests for Business Logic layer and mocking other parts. Is it possible and reasonable to do TDD in this case?
Sì, in effetti è altamente raccomandato rispetto all'atteggiamento "unit test tutto".
Ricorda, la logica aziendale è la cosa interessante che prende le decisioni. Tutto il resto è solo un noioso codice di infrastruttura che collega le connessioni.
L'infrastruttura noiosa è facile da leggere ma difficile da testare. Il punto delle prove è rendere il codice facile da leggere per gli umani. Il noioso codice di facile lettura non richiede test unitari.
Questo è il motivo per cui non testiamo le GUI unitarie. Invece spostiamo tutta la logica interessante dalla GUI e la mettiamo in qualche posto testabile.
Il nome per separare il codice difficile da verificare da codice interessante è Il modello di oggetto umile 1 , 2
TDD funziona meglio quando segui questo schema. In pratica dice che se il tuo codice è interessante e difficile da testare, allora separa le cose interessanti dalla roba difficile da testare. Questo può essere semplice come trasformare una funzione in due. Un test unitario. Uno non lo fai.
Pensare di dover testare tutto in TDD è un modo rapido per convincere le persone che TDD non funziona. No, non è quello per cui è.
Tieni presente che ci sono molti altri tipi di test oltre ai test unitari. Quelli lenti sono talvolta chiamati test di integrazione. Questo è quando si verifica ciò che accade quando si collegano le cose che TDD isola. Questi test mostrano per lo più che le connessioni funzionano. Questi test sono lenti. Non li esegui spesso. Assicurati di eseguirli almeno una volta prima di pubblicare.
TDD parla dei test veramente veloci. Così veloci li esegui ogni volta che compili. Alcuni li eseguono ad ogni battuta. 3 Quindi, per favore, non confondere questi due diversi tipi di test e incolpare l'incubo risultante su TDD. Non è colpa sua.
Usa TDD per quello che è: le cose interessanti.
In senso stretto no.
TDD richiede che tutto ciò che scrivi abbia un test.
Tuttavia, sappiamo tutti che alcuni test sono più utili di altri. Se disponi di regole aziendali e test complicati che convalidano le tue regole aziendali in modo che corrispondano alle specifiche, questi sono test piuttosto utili.
Se arrivo come nuovo sviluppatore e interrompo il codice di lettura del database, probabilmente posso vederlo rotto e sapere come risolverlo. Sarebbe bello avere un test ma non essenziale.
Se interrompo un oscuro caso di regole aziendali che è stato progettato mesi o anni fa, allora potrei anche non notare che qualcosa non funziona senza quei test unitari.
Leggi altre domande sui tag tdd unit-testing domain-driven-design