TDD fondamentale: bloccato con la scrittura di un test in modo da poter scrivere il codice che voglio

Question

TDD fondamentale: bloccato con la scrittura di un test in modo da poter scrivere il codice che voglio

#1 da (4 voti)
#2 da (2 voti)

1

Ho una lezione di stagione. Questa stagione ha alcune proprietà: tra queste, una lista di giochi. Questo dovrebbe essere compilato dalla stessa fonte che ha popolato il resto delle proprietà Season.

Ho eseguito un test per verificare che tutti gli elementi in tale elenco siano di tipo Gioco.

Non è richiesto che una Stagione debba contenere dei Giochi, quindi testare che la lista non sia vuota non sarebbe del tutto corretta, tuttavia la stagione di test che sto usando ha molti giochi.

Scrivere "la quantità minima di codice per eseguire un passaggio di prova" è già fatto, perché è la lista vuota (quindi non ci sono oggetti di gioco non).

Quale sarebbe il modo fondamentale di TDD per analizzare il codice di produzione + aggiungere giochi all'oggetto Season?

Il modo pragmatico dovrebbe essere testato tramite la dimensione?

Un'alternativa sarebbe quella di generare l'elenco di giochi nel mio test e vedere se Season.games == list_of_games

Il problema è che ci sono un mucchio di relazioni estere che entreranno in quei giochi, rendendo il codice di prova equivoco al metodo che sto testando - che non penso sia il modo in cui dovrebbe lavoro.

O dovrei costruirli "a mano" dai dati del test - invece di analizzarli?

tdd language-agnostic unit-testing

posta Travis 12.05.2013 - 15:05

fonte

2 risposte

Leggi altre domande sui tag tdd language-agnostic unit-testing

Esiste un concetto di variabile con fasi di inizializzazione: non inizializzato, inizializzato, immutabile? Cosa c'è di meglio: più voci sql o una voce sql con un campo lista?

score 4 · Answer 1

Se ho capito bene, c'è un requisito che stabilisce che "una stagione ha una lista di 0 o più oggetti di gioco .. Questo elenco non deve contenere oggetti di altri tipi".

Il modo più semplice per verificare questo requisito è tramite il metodo per aggiungere elementi all'elenco. Hai un test per verificare che sia possibile aggiungere oggetti di gioco all'elenco, e hai un secondo test per verificare che l'aggiunta di oggetti non di gioco abbia esito negativo.

(Eccezione: se si utilizza un linguaggio di tipo statico, come C ++, C # o Java, e si utilizza il sistema di tipi per assicurarsi che solo gli oggetti di gioco possano essere aggiunti all'elenco, il secondo test viene effettivamente eseguito dal compilatore ogni volta che si scrive codice per aggiungere un elemento all'elenco. Non è necessario quindi scrivere il test da soli.)

score 2 · Answer 2

Estrarre dati da XML o JSON sembra sempre un po 'difficile da fare in un modo TDD. Si finisce con un sacco di codice che assomiglia a:

void parseElement(XMLElement element)
{
     name = element.getAttribute("name");
     home_team = teams.lookup( element.getAttribute("home") );
     away_team = teams.lookup( element.getAttribute("away") );
}

Posso aggiungere delle asserzioni per verificare il nome e i team, ma è piuttosto difficile giustificarlo. Il codice è così semplice che il tentativo di verificare che funzioni effettivamente sembra non valere la pena. Certo, ha senso eseguire il codice e assicurarsi che non vada in fiamme, e ha senso controllare qualsiasi azione non banale. Ma vale davvero la pena asserire ogni incarico? Tutto quello che stai facendo davvero sta dicendo in modo ridondante la stessa cosa.

Questo è quello che penso tu stia colpendo. È molto impegnativo verificare che la deserializzazione sia corretta, ma non sembra davvero utile. Ecco perché sei riluttante a creare un elenco di giochi da testare. Questo è un grande sforzo per poco guadagno.

La mia soluzione è ideare un framework per estrarre informazioni, testarlo e, soprattutto, fidarsi del fatto che funzioni quando applicato ai tuoi oggetti. Non so quale lingua stai usando, ma qui c'è una versione pythonish.

class Season(XMLExtractable):
    XML_FIELDS = {
         'name' : AttributeGetter('name', str),
         'games' : ChildNodeGetter('game', Game),
         ...
    }

Il ddt XML_FIELDS mi dice dove ogni attributo dovrebbe ottenere i suoi dati. Gli oggetti costruiti qui hanno metodi per recuperare il valore. Ho testato tutti quegli oggetti, e per la maggior parte posso solo fidarmi che lavorino qui. Fondamentalmente, trasferiamo tutta la ridondanza in dati e operiamo su quei dati. Possiamo testare le nostre operazioni sui dati, ma supponiamo che i dati siano corretti.