2 domande su TDD

Question

2 domande su TDD

#1 da (5 voti)

3

Sto appena iniziando a fare i conti con TDD, e ho 2 domande veloci;

Suppongo che se stessimo scrivendo software per una società di software, che TDD avrebbe funzionato insieme al design del software? tutti i diagrammi UML, ERD, diagrammi di flusso ecc ...

La mia seconda domanda è, nel modo in cui sto facendo i miei test al minuto, penso a ciò che verrà chiamato nel codice (ad esempio un metodo) e penso a tutti i possibili input errati e input corretti. Quindi, per esempio, supponiamo di sapere che ho bisogno di chiamare un "loadfile", quindi scrivo solo il codice sufficiente per far passare il test ...

Ma poi comincio anche a pensare, cosa succede se non si specifica un parametro o un file non valido, quindi scrivo qualche altro test per verificare le eccezioni - il che comporta l'aggiunta di un po 'di logica nel metodo ( quindi viene restituita l'eccezione corretta

Questo è l'approccio corretto al TDD?

tdd unit-testing c#

posta binks 13.11.2014 - 09:56

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing c#

Quale è più semplice per la chiamata client REST per restituire JSON - JQuery / JavaScript o Spring RestTemplate? [chiuso] Devo controllare l'integrità nel mio codice applicazione o rinviare al database? [duplicare]

score 5 · Accepted Answer

TDD è principalmente una tecnica di implementazione , quindi funziona come ortogonale come scrivere un altro codice per le tecniche di progettazione "grafica" che hai citato. (Se queste ultime tecniche sono utilizzate in tutte le società di software, per tutti i tipi di software professionale, è una domanda completamente diversa.) Quando si hanno diagrammi UML sul livello di astrazione dell'API della classe pubblica, con firme del metodo, quindi feedback dall'implementazione livello, o forse da test codificati possono influenzare parti della tua API di classe pubblica e quindi influenzare i tuoi modelli UML, ma questo è sempre il caso, se stai facendo TDD o meno.

Se comprendo correttamente la tua seconda domanda, stai parlando di piccoli cicli di test di scrittura, implementazione, estensione dei test, estensione dei metodi implementati per soddisfare i nuovi test? In realtà, questo è esattamente come idealmente dovrebbe essere fatto TDD "dal libro".

In effetti, ci sono alcuni miti (IMHO errati) su cui il TDD parla di scrivere "tutti i test prima". Penso che sia un equivoco: TDD parla di scrivere idealmente solo un test uno alla volta, quindi implementare un po ', scrivere il prossimo test one e così via.