A che punto del ciclo di vita di un progetto inizi a scrivere dei test? [duplicare]

Il TDD ruota principalmente attorno ai test unitari, questa risposta lo coprirà.

Perché realizzi applicazioni? Li fai vedere che C # funziona bene, o li fai per risolvere un problema presentato dal tuo cliente (tieni presente che a volte il cliente potrebbe essere anche tu?)

Se non sei uno sviluppatore .NET che lavora per la società Microsoft e sei effettivamente responsabile della manutenzione del linguaggio C #, è quasi sempre il secondo caso. Stai provando a risolvere un problema, un problema che ha alcune regole.

Le regole presentate sono la tua logica aziendale, il tuo dominio. Una volta iniziato a lavorare sul tuo dominio, questo è l'ultimo momento in cui dovresti iniziare a scrivere test.

I più recenti? Sì. Parlando da una posizione di uno sviluppatore PHP senior, anche se è bello che PHP ti permetta di fare un sacco di cose, un linguaggio compilato non (come restituire due oggetti completamente diversi da un metodo), porta a un codice errato. Quindi, in molti casi, è meglio scrivere semplicemente il livello del database e non dipendere da una soluzione già esistente con metodi statici, ecc. Se costruisci questo livello, potresti prendere in considerazione anche la scrittura di test per questo, per assicurarti che cosa ha scritto opere.

In generale, non è mai troppo presto per iniziare a scrivere test di unità, ma c'è un punto in cui diventa troppo tardi e inutile. Come un'unità che testa i tuoi controllori. Ho visto persone farlo e non è quello che dovrebbe fare il test unitario. I tuoi controller sono una procedura, che contiene fabbriche per servizi, istanziali, che funzionano con i tuoi oggetti di dominio, non sono unità. Se vuoi testare i tuoi controller, usa invece suite di test di integrazione .

Che cosa dovrebbe essere sempre testato allora?

Vuoi avere test unitari per il tuo dominio, la tua logica aziendale. Se hai questo e le tue regole aziendali sono davvero lì, non devi preoccuparti del resto dell'applicazione, poiché dovrebbe eseguire solo operazioni CRUD di base su dati, che è valido (grazie per test e buoni modelli di dominio).

TDD Dal punto di vista del ciclo di vita

TDD significa che scrivi prima i test e poi scrivi il codice. Quando lavori su un progetto, passi attraverso diverse fasi.

1. Scegliere la tecnologia giusta : non sai quale linguaggio di programmazione sceglierai, ma non puoi semplicemente scrivere test.
2. Scegli il tuo modello architettonico : hai scelto il linguaggio di programmazione, ma non hai idea di come sarà strutturato il tuo progetto. Saranno moduli, servizi, MVC? Nel tuo caso è molto probabile che sia il pattern MVVM. Tutta la tua architettura è considerata un'unità? Io non la penso così Non è necessario testare l'architettura dell'applicazione.
3. Progettazione del livello del dominio : questa è la parte in cui i requisiti funzionali e non funzionali dell'utente sono accompagnati dalle regole del client e vengono implementati. Prima di questa fase, devi scrivere test e quindi fornire l'implementazione per farli passare.
4. (facoltativo) Progettazione di servizi, che utilizzano i tuoi modelli di dominio : puoi creare servizi unendo più operazioni di dominio in un unico processo, proprio come una facciata. Puoi scrivere dei test prima di progettare questi servizi, ma è un'attività facoltativa.

Come detto prima, per assicurarti che la tua applicazione (la parte del cablaggio) funzioni come previsto, dovresti utilizzare i test di integrazione invece dei test delle unità.

At what point in that process should I really begin testing?

Bene, hai chiesto espressamente circa tdd , quindi c'è davvero solo una risposta corretta: Prima di fare qualsiasi altra cosa.

Lo sviluppo e il design guidato dal test si chiama Test- Driven , perché i Test indirizzano allo sviluppo e alla progettazione. I test ti dicono quando iniziare a scrivere il codice. Ti dicono cosa scrivere. Ti dicono come scriverlo. Ti dicono cosa scrivere dopo. Molto importante, ti dicono quando hai finito di scrivere.

Per farlo, devono esistere. La prima cosa che fai, prima di fare qualsiasi cosa altro, è scrivere un test.

Nota: non sto dicendo che questo è il modo solo per farlo, ma tu hai chiesto informazioni su TDD, e se non lo segui, allora non è TDD.

Il ciclo TDD generale ha questo aspetto (sono in realtà 4 cicli, nidificati in 3 livelli):

1. Scegli una storia utente (il modo in cui lo fai è al di fuori dell'ambito di TDD, puoi usare Scrum o XP, ad esempio, per capire quale storia scegliere in seguito).
2. Scrivi il test di accettazione più semplice che potrebbe non riuscire per i criteri di accettazione di tale user story.
3. Esegui i test di accettazione.
4. Guarda il test di accettazione (e solo che test!) hai appena scritto un errore.
5. Verifica che non funzioni per i giusti motivi.

6. Finché il test fallisce, ripeti:

   1. Scegli un'unità di comportamento indipendente
   2. Scrivi il test unitario più semplice che potrebbe fallire per quell'unità di comportamento
   3. Esegui i test dell'unità.
   4. Guarda il test dell'unità (e solo quel test!) hai appena scritto un errore.
   5. Verifica che non funzioni per i giusti motivi.

   6. Finché il test fallisce, ripeti:

      1. Scrivi il codice più semplice che potrebbe modificare il messaggio di errore

   7. Non appena il test passa, finché c'è qualcosa da migliorare, ripeti:

      1. Rifattore senza pietà

Keith Braithwaite ha creato un esercizio che chiama TDD As If You Significa . Consiste in un insieme di regole (basate su Tre regole del TDD dello zio Bob Martin , ma molto più severe) che devi rigorosamente seguire e che sono progettati per orientarti verso l'applicazione di TDD in modo più rigoroso. Funziona al meglio con la programmazione delle coppie (in modo che la tua coppia possa essere sicura che non infrangi le regole) e un istruttore.

Puoi leggere di più su queste due domande:

• Come eseguire lo sviluppo guidato dai test
• Implementazioni economiche nel TDD fondamentale

Di solito non puoi scrivere un test per un metodo prima che sia stata scritta almeno la dichiarazione del metodo, perché il test non verrà compilato. E non è possibile eseguire il test prima che almeno una definizione vuota per il metodo sia scritta, perché il test non si collegherà. Quindi l'ordine migliore è:

(a) Pianifica ciò che vuoi fare. (b) Scrivi la dichiarazione per il metodo. (c) Scrivi il test unitario. (d) Scrivi una definizione vuota del metodo. (e) Eseguire il test dell'unità, assicurandosi che venga segnalato un errore. (f) Implementare il metodo. (g) Eseguire nuovamente i test di unità per assicurarsi che abbiano successo. (h) Con la tua nuova visione del problema, migliora i test unitari e migliora il metodo se necessario.