TDD: come testare il modello di dominio

Question

TDD: come testare il modello di dominio

#1 da (3 voti)

2

Quando pratichi TDD , come collaudi un modello di dominio? Se non si esegue il test, come si tiene conto della copertura del codice? Vogliamo avere una copertura del 100% (o il più possibile), ma nonostante le ore di formazione video non riusciamo a trovare la soluzione migliore.

AGGIORNAMENTO: Dato un modello di dominio, desidero scrivere Utente che ha proprietà: Id (chiave primaria), FirstName, LastName, tenantId (chiave esterna). Preferisci creare questo modello senza copertura di prova? Se è così, allora inizi il tuo progetto con la copertura del codice 0%, giusto? Allora stai iniziando a giocare male. Ma in TDD puro, non dovresti scrivere codice senza un test. Quindi cosa faresti?

Facciamo un ulteriore passo avanti. Cosa succede se hai un comportamento - ma solo un po '? Ora il tuo utente ha Id (chiave primaria), FirstName, LastName, tenantId (chiave esterna) e birthDate . Quindi hai un metodo / funzione per calcolare l'età in base alla data di nascita. Sento che dovrei scrivere test prima del calcolo dell'età, ma non prima del modello. Come spiegheresti questo paradosso?

tdd test-coverage domain-model

posta bjscharf 28.09.2015 - 21:23

fonte

1 risposta

Leggi altre domande sui tag tdd test-coverage domain-model

Come si memorizza un grafico uno-a-molti? Passando radice o passando radice e bambini separatamente? TDD Duplica test su classi correlate

score 3 · Answer 1

Ecco perché la copertura del codice è una metrica terribile.

Se hai un semplice DTO (una classe con solo proprietà che contengono dati), c'è un valore molto piccolo nel testare i metodi che ottengono e impostano tali proprietà. Puoi farlo e la copertura del tuo codice aumenterà sicuramente, ma è un test inutile. Stai testando la lingua e non il codice. Se cerchi una buona copertura, cerca di ottenere una copertura del codice che faccia effettivamente qualcosa.

L''unico codice di scrittura per eseguire un test fallito' è una regola molto buona, ma non è pensata per essere invocata ad ogni turno. Infatti, anche i costruttori sono cattivi quindi probabilmente non dovremmo mai usarli, giusto? Beh, non proprio. Ma è molto più facile (e più accattivante) dire "mai" anziché "per lo più mai, a meno che ...". La regola per cui non si dovrebbe mai scrivere codice a meno che non sia stata scritta per eseguire un test fallito è la stessa.

Con il tempo e l'applicazione di TDD al tuo sviluppo arriva una quantità di esperienza che ti permette di vedere dove la regola dovrebbe essere applicata e dove non dovrebbe essere applicata.