Quale classe per avviare TDD dell'applicazione di gioco di carte? Quali sono i prossimi 5-7 test?

E riguardo il seguito. Il {} è il suggerimento per il prossimo passo e dopo vorrei entrare anche in attributi specifici.

1. Esiste un mazzo di carte {Pack}
2. Il pacchetto ha 52 carte {Card and Pack - numero di carte}
3. Le carte hanno 4 semi {attributo Card}
4. Ogni seme ha A, 2-10, J, Q, K {attributo carta}
5. È selezionato un gioco. {Istanza di gioco}
6. I giocatori sono selezionati {istanze del giocatore}
7. Le carte vengono mescolate. {Shuffle method (s)}
8. Le carte vengono distribuite. {Metodi di offerta}
9. Ogni persona suona. {Metodo / i di gioco}
10. Una persona vince. {Metodo Part of Play, forse call to Win method}
11. Fine del gioco. {Metodo EndGame}

Vorrei iniziare con gli oggetti di livello più basso, quegli oggetti che potresti aver bisogno di scrivere per alcuni test, perché in genere restituiscono proprietà come Suit e Color.

Una volta che hai gli oggetti di base, puoi iniziare ad aggiungere test per i metodi comportamentali e per i metodi che causano l'interazione tra questi oggetti di base.

Se vuoi veramente abbracciare lo sviluppo basato sui test, puoi iniziare dimenticando che hai scritto un codice. (Non buttarlo via, mettilo da parte nella tua mente.) Poi chiediti quale test avresti scritto se non avessi ancora scritto alcun codice. Cosa vorresti affermare per primo? Rispondi a questa domanda e avvia il ciclo TDD:

1. Scrivi un test in errore.
2. Cambia il tuo codice per farcela.
3. Ripeti.

Non importa dove inizi, purché abbia senso per te. Sembra che tu abbia già una solida conoscenza di come vuoi che l'applicazione sia progettata. È fantastico, quindi non aver paura di scrivere test scadenti. Col passare del tempo, imparerai a migliorarlo.

Ricorda che i test servono a impedire a te (e ad altri) di alterare negativamente il tuo codice. Si tratta di un "contratto" che stai definendo in modo da non avere solo un test eseguibile, ma un riferimento a come avresti previsto che il tuo codice avrebbe funzionato. Quindi inizia scrivendo dei test che descrivono ciò che il tuo codice dovrebbe fare. Se non sei ancora sicuro di come funzionerà qualcosa, gioca con le idee (scrivendo dei test) finché non avrà un senso.

Tecnicamente non puoi fare TDD su codice già esistente. In TDD, i test sono la base per il tuo progetto, qui il design è già fatto e poi vuoi refactoring.

La mia raccomandazione è:

1. Scrivi i test in base al progetto già implementato (cerca i casi di test su ciascun metodo) in modo da ottenere la copertura del codice
2. Assicurati che tutti i test superino
3. Iniziare a fare refactoring e / o nuove implementazioni, ogni volta che stai per implementare una nuova funzionalità o apportare una modifica al progetto (aggiungendo metodi, cambiando un algoritmo, esegui verifiche aggiuntive, ecc.) scrivi prima un test che fallisce
4. Cambia il tuo codice per superare il test fallito
5. Vai a 3

La classe non ha importanza, la domanda è: come fai a entrare il processo ?

Adattare i test a un'applicazione già esistente può essere piuttosto difficile e si potrebbe finire per ristrutturare il codice in modo significativo. Potresti ristrutturarlo così tanto che la ristrutturazione potrebbe sembrare come se stessimo iniziando da zero.

Dal momento che sembra che ti stia semplicemente "divertendo" potresti trarne di più, almeno dal punto di vista del design, partendo da zero.

Penso che dovresti assolutamente testare i tuoi modelli. Inizia con i modelli "più piccoli", come ad esempio gli oggetti Carta. I tuoi test verificheranno questi lavori. Puoi quindi passare ai modelli Mano. Quindi il Consiglio.

In questo modo costruisci una gerarchia di test che iniziano con comportamenti semplici e si accumulano in comportamenti più complessi.

Ad esempio, supponiamo di avere un metodo chiamato getHandValue che calcola un valore di mano in base al valore delle carte nella mano. Beh, probabilmente vorrai testare il metodo getCardValue prima di testare il metodo della mano perché il metodo hand usa comunque il metodo card.

Inoltre, puoi usare gli oggetti mock per sbarazzarti del lavoro di installazione non necessario.

Ad esempio, supponi di avere una "tavola" con un metodo getBoardValue . Diciamo che questo metodo usa tutte le mani attualmente in gioco per calcolarne il valore. Invece di creare una mano e quindi creare carte da aggiungere alla mano, puoi semplicemente creare un oggetto mock hand che restituisce un valore predeterminato. Ora non devi fare tutte queste impostazioni e ricordare quali carte hai aggiunto alle mani.

Alcune cose sono più difficili da testare ed è qui che entrano in gioco le decisioni di design.

Inoltre, non testare direttamente le interfacce (solo nel caso in cui ci si pensasse). Verifica solo le implementazioni poiché sono le implementazioni che effettivamente eseguono il lavoro.