Come scrivere il primo test per una funzionalità "aggiungi"

Question

Come scrivere il primo test per una funzionalità "aggiungi"

#1 da (4 voti)

5

Ho avuto problemi nel trovare un buon titolo della domanda, quindi sentiti libero di migliorare su questo.

Desidero implementare un Sistema componenti Entity in C ++ e desidero utilizzare TDD per la prima volta. Ora ho dei dubbi su quanto sia utile TDD quando l'obiettivo "architettura" è già specificato, ma voglio provarlo comunque. Il mio problema è più un problema TDD, e potrei averlo eseguito anche in un altro contesto:

Il primo test doveva controllare che io possa aggiungere un Component a un Entity come Entity dovrebbe "possedere" un insieme di Component s (forse questo è un test negativo e il problema sta già qui?). Finora non esiste alcun codice e sto affrontando un dilemma che potrebbe non essere uno. Potrei scrivere un test che faccia questo:

Entity e;
Component c;
e.add(c);

Ma come potrei affermare che add ha funzionato correttamente? So che avrò bisogno di un qualche tipo di metodo has_component prima o poi, ma non dovrei implementare funzionalità aggiuntive ora, o dovrei? Potrei anche fare in modo che Entity abbia un tipo di lista nella sua interfaccia pubblica e usarlo nel test, e refactoring che "allontana" più tardi.

Qual è l'approccio corretto qui? Potrebbe essere la mia mentalità per TDD è completamente fuori, quindi sono grato per qualsiasi input!

tdd unit-testing c++

posta InvisiblePanda 01.11.2016 - 18:02

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing c++

Faking - Dipendenza vs dettagli interni Post-condizione nei casi di test

score 4 · Accepted Answer

Il tuo primo test è un buon inizio. Forse pensa al controllo degli errori: c'è un codice di ritorno da aggiungere, per dire che ha funzionato o no? O dovrebbe fare un'eccezione se qualcosa va storto?

Approccio preferito

Sapendo che avrai bisogno di un metodo has_component() per la classe Entity , aggiungilo alla definizione della classe, con un'implementazione stub che restituisce sempre false (e un grande commento // TO DO !! ).

Il tuo prossimo test sarà quindi:

assert(! e.has_component(c) ); 
e.add(c);
assert(e.has_component(c)); // or return FAIL to your test framework.

Il principio è che il test fallirà fino a quando entrambe le funzioni non saranno corrette.

Quali sono le alternative

usa un membro più semplice, come number_of_components() per verificare che sei sulla strada giusta (ad esempio, il numero aumenta quando aggiungi un nuovo componente, il numero rimane lo stesso quando aggiungi lo stesso componente due volte).
lascia che il codice di prova controlli le parti interne del tuo Entity . Non mi piace questo approccio, perché infrange le regole dell'incapsulamento.
crea un test doppio che fornisce una risposta simulata / simulata per has_component() . Sarebbe una caratteristica molto complessa, questa sarebbe la strada da percorrere. Ma per caratteristiche semplici come qui, questo potrebbe essere eccessivo.
se tu avessi una funzione di distribuzione che inoltra le chiamate da Entity a Components potresti usarla per controllare se c reagisce.