TDD con requisiti non chiari

Question

So che TDD aiuta molto e mi piace questo metodo di sviluppo quando si crea un test per la prima volta e si implementa la funzionalità. È un modo molto chiaro e corretto.

Ma a causa di qualche sapore dei miei progetti succede spesso che quando inizio a sviluppare qualche modulo so molto poco di ciò che voglio e come sarà alla fine. I requisiti appaiono mentre sviluppo, potrebbero esserci 2 o 3 iterazioni quando cancello tutto o parte del vecchio codice e scrivo nuovo.

Vedo due problemi: 1. Voglio vedere il risultato il prima possibile per capire se le mie idee sono corrette o sbagliate. I test unitari rallentano questo processo. Succede spesso che scrivo dei test unitari dopo che il codice è finito, ciò che è noto per essere un cattivo pattern. 2. Se prima scrivo i test, devo riscrivere non solo il codice due volte o più volte ma anche i test. Ci vuole molto tempo.

Qualcuno potrebbe dirmi come può essere applicato TDD in tale situazione?

Grazie in anticipo!

Answer 1

Voglio vedere il risultato il prima possibile per capire se le mie idee sono corrette o sbagliate. I test unitari rallentano questo processo.

Non sono d'accordo. I test unitari e TDD possono spesso accelerare i risultati perché ti costringono a concentrarti sui risultati piuttosto che implementare tonnellate di codice che potresti non aver mai bisogno. Ti consente anche di eseguire le diverse parti del tuo codice mentre le scrivi, in modo da poter vedere costantemente quali risultati stai ottenendo, piuttosto che dover attendere che l'intero programma sia finito.

Answer 2

TDD ti aiuta a esprimere l'intento del tuo codice. Ciò significa che scrivendo il test, devi dire cosa ti aspetti dal tuo codice. Il modo in cui le tue aspettative sono soddisfatte è quindi secondario (questa è l'implementazione). Poniti la domanda: "Che cosa è più importante, l'implementazione o quale è la funzionalità fornita?" Se è l'implementazione, non è necessario scrivere i test. Se è la funzionalità fornita, scrivere prima i test ti aiuterà in questo.

Un'altra cosa importante è che con TDD non implementerete funzionalità che non saranno necessarie. Scrivi solo codice che deve soddisfare l'intento. Questo è anche chiamato YAGNI (non ne avrai bisogno).

Answer 3

Trovo che TDD funzioni particolarmente bene in questo tipo di situazione; in effetti, direi che avere requisiti poco chiari e/o mutevoli è in realtà molto comune.

Trovo che l'utilizzo ottimale di TDD assicuri che il codice esegua ciò che ci si aspetta che faccia. Quando scrivi un codice, dovresti sapere cosa vuoi che faccia, se i requisiti sono chiari o meno. La forza di TDD qui è che se c'è un cambiamento nei requisiti, puoi semplicemente cambiare uno o più dei tuoi test unitari per riflettere i requisiti modificati, e quindi aggiornare il tuo codice assicurandoti di non infrangere gli altri (invariato) funzionalità.

Penso che una cosa che fa inciampare molte persone con TDD è l'ipotesi che i test tutti debbano essere scritti in anticipo. Penso che sia più efficace usare la regola empirica per non scrivere mai alcun codice di implementazione mentre tutti i test stanno passando; questo assicura semplicemente che tutto il codice sia coperto, assicurandoti anche che tu stia controllando che tutto il codice faccia quello che vuoi fare senza preoccuparti di scrivere tutti i tuoi test in anticipo.

Answer 4

In questa prima fase del prototipo trovo che sia sufficiente scrivere codice verificabile. Cioè, quando scrivi il tuo codice, pensa a come rendere possibile testare, ma per ora concentrati sul codice stesso e non sui test.

Si dovrebbe avere i test in atto quando si commette qualcosa però.

Answer 5

Ecco un post sul blog che ho trovato molto efficace nello spiegare l'uso di TDD su una scala di processo di progettazione molto iterativa: http://blog.extracheese.org/2009/11/how_i_started_tdd.html.

Answer 6

L'utilizzo di TDD potrebbe effettivamente farvi scrivere codice più velocemente - non essere in grado di scrivere un test per uno scenario specifico potrebbe significare che c'è un problema nei requisiti.
Quando utilizzi TDD, dovresti trovare questi posti problematici più velocemente anziché dopo aver scritto l'80% del tuo codice.

Ci sono alcune cose che puoi fare per rendere il vostro test più resistenti al cambiamento:

1. Si dovrebbe cercare di riutilizzare il codice all'interno i test in una forma di fabbrica metodi che crea il test oggetti insieme ai metodi di verifica che controlla il risultato del test. Questo modo se si verificano alcuni importanti comportamenti si verifica nel codice in cui è necessario meno codice da modificare nel test.

2. Usa CIO contenitore invece di passare argomenti per le vostre classi principali - di nuovo se la firma del metodo modifiche non è necessario cambiare tutti i test.

3. Rendi il test dell'unità breve e isolato: ogni test dovrebbe verificare solo un aspetto del codice e utilizzare il framework di simulazione/isolamento per rendere il test indipendente da oggetti esterni.

4. Codice di prova e scrittura solo per la funzione richiesta (YAGNI). Prova a chiedersi quale valore il mio cliente riceverà dal codice che sto scrivendo. Non creare un'architettura complicata invece di creare le funzionalità necessarie pezzo dopo pezzo mentre si esegue il refactoring del codice man mano che si procede.

Answer 7

Non c'è allontanarsi da esso - se si sta misurando quanto tempo ci vuole per codificare solo da quanto tempo ci vuole a scrivere classi, ecc, quindi ci vorrà più a lungo con TDD. Se sei esperto aggiungerà circa il 15%, se sei nuovo ci vorrà almeno il 60% in più se non di più.

MA, in generale, sarai più veloce. Perché?

• scrivendo un test prima si specificano quello che vuoi e fornire proprio questo e niente di più - e quindi di risparmiare tempo a scrivere codice non utilizzato
• senza prove, si potrebbe pensare che i risultati sono così evidenti che ciò che si hai fatto è corretto - quando non lo è. I test dimostrano che quello che hai fatto è corretto.
• si otterrà un feedback più velocemente da test automatizzati che facendo test manuali
• con manuale di testare il tempo necessario per testare tutto come l'applicazione cresce rapidamente in aumento - che significa che avrete smettere di farlo
• con test manuali E ' facile da fare errori e 'vedere' qualcosa che passa quando non lo è, questo è particolarmente vero se li stai eseguendo ancora e ancora e ancora
• (buona) unit test ti danno un secondo client al tuo codice che spesso evidenzia problemi di progettazione che potresti perdere altrimenti

Aggiungete tutto questo e se misurate dall'inizio alla consegna e TDD è molto, molto più veloce - ottenete meno difetti, state prendendo meno rischi, procedete a una velocità costante (il che rende la stima più semplice) e l'elenco continua .

TDD ti renderà più veloce, nessuna domanda, ma non è facile e dovresti concederti un po 'di spazio per imparare e non scoraggiarti se inizialmente sembra più lento.

Infine dovresti esaminare alcune tecniche di BDD per migliorare ciò che stai facendo con TDD. Inizia con la funzione che desideri implementare e scendi nel codice da lì tirando fuori storie e quindi scenari. Concentrati sull'implementazione dello scenario della tua soluzione per scenario in sezioni verticali sottili. Fare questo aiuterà a chiarire i requisiti.

Answer 8

IMHO, il tuo problema principale è quando devi cancellare del codice. Questo è rifiuti e questo è ciò che deve essere affrontato prima.

Forse potresti prototipare o utilizzare "soluzioni spike" per convalidare i requisiti e le tue idee quindi applicare TDD sul codice reale, una volta che i requisiti sono stabili.

Il rischio è di applicare questo e di dover spedire il prototipo.

Inoltre, è possibile testare prima il "percorso soleggiato" e implementare solo il rimanente come la gestione degli errori ... dopo che i requisiti sono stati bloccati. Tuttavia, la seconda fase dell'implementazione sarà meno motivante.

Quale processo di sviluppo stai utilizzando? Sembra agile mentre stai eseguendo iterazioni, ma non in un ambiente che lo supporta completamente.

Answer 9

Joshua Block ha commentato qualcosa di simile nel libro "Coders at work". Il suo consiglio era di scrivere esempi di come l'API sarebbe stata usata (circa una pagina di lunghezza). Quindi pensa molto agli esempi e all'API e aggiusta l'API. Quindi scrivi le specifiche e i test unitari. Siate pronti, tuttavia, a rifattorizzare l'API e riscrivere le specifiche mentre implementate l'API.

Answer 10

TDD, per quasi tutti, rallenterà lo sviluppo iniziale. Quindi, se la velocità di sviluppo iniziale è 10 su una scala 1-10, con TDD potresti ottenere un 8 se sei abile.

È lo sviluppo dopo il quel punto che diventa interessante. Man mano che i progetti diventano più grandi, l'efficienza di sviluppo generalmente diminuisce, spesso fino a 3 sulla stessa scala. Con TDD, è ancora possibile rimanere nella gamma 7-8.

Cercare "debito tecnico" per una buona lettura. Per quanto mi riguarda, qualsiasi codice senza test unitari è effettivamente un debito tecnico.

Answer 11

Quando mi occupo di requisiti non chiari, so che il mio codice dovrà cambiare. Avere test solidi mi aiuta a sentirmi più a mio agio nel cambiare il mio codice. Praticare TDD mi aiuta a scrivere test solidi, e questo è il motivo per cui lo faccio.

Sebbene TDD sia principalmente una tecnica di progettazione, ha un grande vantaggio nella tua situazione: incoraggia il programmatore a considerare dettagli e scenari concreti. Quando faccio questo, noto che trovo abbastanza rapidamente lacune o incomprensioni o mancanza di chiarezza nei requisiti. L'atto di provare a scrivere prove mi costringe a gestire la mancanza di chiarezza nei requisiti, piuttosto che cercare di spazzare quelle difficoltà sotto il tappeto.

Quindi, quando ho dei requisiti poco chiari, pratizzo TDD sia perché mi aiuta a identificare i problemi specifici dei requisiti che ho bisogno di affrontare, ma anche perché mi incoraggia a scrivere codice che trovo più facile da cambiare, come ho capito di più cosa ho bisogno di costruire