Un SÌ clamoroso con TDD (e con alcune eccezioni)
Va bene il contrario, ma direi che chiunque risponda "no" a questa domanda manca un concetto fondamentale di TDD.
Per me, la risposta è un sonoro sì se segui TDD. Se non lo sei, allora no è una risposta plausibile.
Il DDD in TDD
Il TDD viene spesso citato come avente i principali vantaggi.
-
di difesa
- Assicurandosi che il codice possa cambiare ma non il suo comportamento .
- Ciò consente la pratica così importante di refactoring .
- Ottieni questo TDD o no.
-
design
- Tu specifica cosa dovrebbe fare qualcosa, come dovrebbe comportarsi prima di implementarlo .
- Questo spesso significa decisioni di implementazione più informate .
-
Documentazione
- La suite di test deve essere utilizzata come documentazione specifica (requisiti)
- L'utilizzo di test per tale scopo significa che la documentazione e l'implementazione sono sempre in uno stato coerente: una modifica a una significa una modifica ad un'altra. Confronta con i requisiti di mantenimento e la progettazione su un documento separato di parole.
Separa la responsabilità dall'implementazione
Come programmatori, è terribilmente allettante pensare che gli attributi siano qualcosa di significativo e getter e setter come una sorta di sovraccarico.
Ma gli attributi sono dettagli di implementazione, mentre setter e getter sono l'interfaccia contrattuale che effettivamente fa funzionare i programmi.
È molto più importante sillabare che un oggetto dovrebbe:
Allow its clients to change its state
e
Allow its clients to query its state
quindi come viene effettivamente memorizzato questo stato (per il quale un attributo è il più comune, ma non l'unico modo).
Un test come
(The Painter class) should store the provided colour
è importante per la documentazione parte di TDD.
Il fatto che l'eventuale implementazione sia banale (attributo) e non porti benefici defense dovrebbe essere sconosciuta a te quando scrivi il test.
La mancanza di ingegneria di andata e ritorno ...
Uno dei problemi chiave nel mondo dello sviluppo del sistema è la mancanza di round-trip engineering 1 - il processo di sviluppo di un sistema è frammentato in sottoprocessi disgiunti gli artefatti di cui (documentazione, codice) sono spesso incoerenti.
1 Brodie, Michael L. "John Mylopoulos: semi di cucito della modellazione concettuale." Modellazione concettuale: fondamenti e applicazioni. Springer Berlin Heidelberg, 2009. 1-9.
... e come TDD lo risolve
È la parte documentation di TDD che garantisce che le specifiche del sistema e il suo codice siano sempre coerenti.
Progetta prima, implementa più tardi
All'interno di TDD scriviamo per primi il test di accettazione fallito, solo poi scriviamo il codice che consente loro di passare.
All'interno del BDD di livello superiore, scriviamo prima gli scenari, poi li facciamo passare.
Perché dovresti escludere setter e getter?
In teoria, è perfettamente possibile all'interno di TDD che una persona scriva il test e un'altra per implementare il codice che la rende passata.
Quindi chiediti:
Should the person writing the tests for a class mention getters and setter.
Poiché getter e setter sono un'interfaccia pubblica per una classe, la risposta è ovviamente sì , oppure non ci sarà modo di impostare o interrogare lo stato di un oggetto.
Ovviamente, se scrivi prima il codice, la risposta potrebbe non essere così chiara.
Eccezioni
Ci sono alcune ovvie eccezioni a questa regola - funzioni che sono dettagli di implementazione chiari e chiaramente non fanno parte del design del sistema.
Ad esempio, un metodo locale 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
O la funzione privata square() qui:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
O qualsiasi altra funzione che non fa parte di un'interfaccia public che richiede l'ortografia nella progettazione del componente di sistema.