Avvio di un nuovo progetto con TDD

Sto studiando TDD e ho letto che ti aiuta anche a definire il design dell'app, giusto?

Così ho deciso di iniziare a creare un nuovo progetto per aiutarmi a capirlo meglio.

Voglio creare un semplice sistema di registrazione utente che chiederà il suo nome, indirizzo e-mail, paese (ne sceglierà uno da un elenco) e numero di telefono.

Quindi la domanda è ...

Ho creato una nuova soluzione in VS 2010, ho aggiunto un nuovo progetto Test e non so quali test scrivere!

Dal momento che mi aiuterà a definire il design, quali test posso scrivere qui?

Grazie per qualsiasi aiuto!

Quando si scrivono unit test, si sta verificando il comportamento della propria applicazione, quindi la domanda importante da porsi è che cosa fa l'applicazione ? Ecco un inizio:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

Solo la creazione di un progetto di test e la scrittura di alcuni metodi di test è una sorta di TDD, ma nella mia esperienza non è di grande aiuto a meno che non si stia lavorando su una libreria in cui è presente un'API nota e le chiamate al metodo corrispondono direttamente a qualcosa previsto dall'utente . Devi trovare il giusto elenco di test e, per un'applicazione non banale, può essere davvero difficile da fare.

Consiglio di provare SpecFlow: continua a definire i test ben separati dall'implementazione e la struttura dei file delle caratteristiche ti costringe a pensare a ciò che stai effettivamente testando.

Quando definisci una funzione scrivi semplicemente qualcosa di simile

When a user is saved
Then the user should exist

Poiché a questo punto non ti trovi in ​​un file di codice, non sei tentato di pensare ai dettagli dell'implementazione come ad esempio quale metodo viene chiamato per creare un utente o persino in quale classe è implementata. Puoi utilizzare i tag per scegliere diverse implementazioni, quindi a questo livello non importa se "l'utente è salvato" significa una chiamata a CreateUser o l'apertura di un browser e l'invio di un modulo.

Dopo aver definito le funzionalità, tutti i test vengono generati e inizieranno a passare man mano che si implementano le definizioni dei passaggi e il codice dell'applicazione effettivo testato.

Per una semplice app puoi semplicemente creare i file delle funzionalità, ma per qualcosa di più complesso è utile mettere insieme una specifica più completa. Per questo utilizzo un'app per la creazione di idee per iPad, ma puoi usare qualsiasi strumento tu ti trovi più a tuo agio.

Inizia con un elenco di funzionalità di alto livello come "Registrazione utente". Questi tendono ad essere troppo ampi per poter scrivere direttamente i test, quindi suddividili in funzioni secondarie che possono essere chiaramente definite e generalmente mappate su un'azione specifica dell'utente come "Salva utente" o "Visualizza utente esistente".

Ognuna di queste funzionalità secondarie avrà bisogno di un elenco di scenari che insieme definiscono completamente se la funzionalità funziona o meno, cose come "Può salvare un utente valido" e "Impossibile salvare un utente con un nome utente duplicato".

Man mano che crei questo elenco, in genere diventerà chiaro dove è necessario modificare la struttura: se non riesci a trovare test di scenario per una funzionalità o se ne finisci con troppe in una funzionalità, tale funzione è probabilmente definita in il livello sbagliato e deve essere diviso o modificato.

Ho trovato utile eseguire il backup dei miei primi esperimenti in TDD con alcune letture e tagliando il codice. L' articolo di Wikipedia sull'argomento è molto buono e ti porterà un'ampia varietà di altre risorse. Cerca le cose di Kent Beck in particolare: una specie di padre di TDD.

Un'altra cosa che potrebbe aiutarti a metterti in pratica è fare dei kata: semplici esercizi di allenamento quasi senza cervello. Roy Osherove ne ha di buoni.

Oltre a ciò, tieni a mente le idee chiave di TDD: scrivi un test alla volta e non proseguire fino a quando non passano tutti i test precedenti. Scrivi solo abbastanza codice per soddisfare il test corrente, evita la tentazione di scrivere di più. Mentre vai, fermati di tanto in tanto e pensa se riesci a ripulire il codice o i test. Sviluppare sempre in un ciclo di rifattore rosso (test fallito), verde (test superato).

E per iniziare, forse inizia con il tuo nome richiesto. Di cosa hai bisogno?

Probabilmente avrai bisogno di una lezione. Scrivi un test per questo (alcune persone lo saltano, ma all'inizio lo fai per l'esercizio) e scrivi la lezione.

Successivamente la tua classe dovrà memorizzare un nome. Scrivi un test per dimostrare che la tua classe può davvero. Quindi scrivere nuovamente il codice per eseguire il test.

Quindi forse hai qualche altra regola aziendale. Forse vuoi che il tuo nome sia composto da un numero minimo di caratteri. Scrivi il test, fallo fallire, scrivi il codice.

E così via...

Penso che non sia possibile darti l'idea del TDD in una breve risposta. Devi "vedere" la pratica del silente, per averne la sensazione. La migliore risorsa che abbia mai trovato su questo argomento è http://pragprog.com/titles/achbd/the-rspec-book . Prima di dirmi che Ruby non è la tua lingua: leggi la prefazione di zio Bob! ;-)

Potresti voler impostare un test che tenti di aggiungere più valori diversi nel campo e-mail, alcuni validi e altri no. Non smettere di sviluppare fino a quando tutti i test non danno il valore atteso. Roba del genere.

Come hai descritto il sistema, esiste un solo test a livello di applicazione:

[Test] public void Save_and_retrieve_user (Nome stringa, Email stringa, ...) {// Salva // Recupera // Verifica}

Mentre affini i requisiti, aggiungi altri test.