Unit test per testare la creazione di un oggetto dominio

Ho un Unit Test, che assomiglia a questo:

[Test]
public void Should_create_person()
{
     Assert.DoesNotThrow(() => new Person(Guid.NewGuid(), new DateTime(1972, 01, 01));
}

Sto affermando che qui viene creato un oggetto Person, ovvero che la validazione non fallisce. Ad esempio, se il Guid è nullo o la data di nascita è precedente al 01/01/1900, la validazione fallirà e verrà generata un'eccezione (il che significa che il test fallisce).

Il costruttore si presenta così:

public Person(Id id, DateTime dateOfBirth) :
        base(id)
    {
        if (dateOfBirth == null)
            throw new ArgumentNullException("Date of Birth");
        elseif (dateOfBith < new DateTime(1900,01,01)
            throw new ArgumentException("Date of Birth");
        DateOfBirth = dateOfBirth;
    }

È una buona idea per un test?

Nota : sto seguendo un approccio classicista all'Unità di test del modello di dominio se questo ha rilevanza.

Questo è un test valido (anche se piuttosto troppo zelante) e a volte lo faccio per testare la logica del costruttore, tuttavia, come ha detto Laiv nei commenti, dovresti chiederti il ​​perché.

Se il tuo costruttore si presenta così:

public Person(Guid guid, DateTime dob)
{
  this.Guid = guid;
  this.Dob = dob;
}

C'è molto senso nel test se lancia? Se i parametri sono assegnati correttamente, posso capire ma il tuo test è piuttosto eccessivo.

Tuttavia, se il test fa qualcosa del genere:

public Person(Guid guid, DateTime dob)
{
  if(guid == default(Guid)) throw new ArgumentException("Guid is invalid");
  if(dob == default(DateTime)) throw new ArgumentException("Dob is invalid");

  this.Guid = guid;
  this.Dob = dob;
}

Quindi il test diventa più pertinente (poiché in realtà stai generando eccezioni da qualche parte nel codice).

Una cosa che direi, generalmente è una cattiva pratica avere molta logica nel tuo costruttore. La validazione di base (come i controlli null / default che sto facendo sopra) sono ok. Ma se ti stai connettendo a database e stai caricando i dati di qualcuno, è lì che il codice inizia a sentire davvero ...

Per questo motivo, se vale la pena testare il costruttore (perché c'è molta logica in corso), forse qualcos'altro non va.

Quasi certamente avrai altri test che coprono questa classe in livelli di logica aziendale, costruttori e assegnazioni di variabili avranno quasi sicuramente una copertura completa da questi test. Pertanto è forse inutile aggiungere test specifici specifici per il costruttore. Tuttavia, nulla è in bianco e nero e non avrei nulla a sfavore di questi test se li analizzassi, ma mi chiederei se aggiungono molto valore al di là dei test altrove nella tua soluzione.

Nel tuo esempio:

public Person(Id id, DateTime dateOfBirth) :
        base(id)
    {
        if (dateOfBirth == null)
            throw new ArgumentNullException("Date of Birth");
        elseif (dateOfBith < new DateTime(1900,01,01)
            throw new ArgumentException("Date of Birth");
        DateOfBirth = dateOfBirth;
    }

Non stai solo facendo la validazione, ma stai anche chiamando un costruttore di base. Per me questo fornisce ulteriori motivi per avere questi test in quanto hanno la logica di costruzione / convalida ora divisa in due classi che diminuisce la visibilità e aumenta il rischio di cambiamenti imprevisti.

TLDR

Vi è un certo valore in questi test, tuttavia è probabile che la logica di convalida / assegnazione sia coperta da altri test nella soluzione. Se c'è molta logica in questi costruttori che richiede test significativi, allora mi suggerisce che ci sia un cattivo odore di codice in agguato lì dentro.

Già una buona risposta qui, ma penso che valga la pena menzionare un'altra cosa.

Quando si esegue TDD "dal libro", è necessario scrivere prima un test che chiama il costruttore, anche prima che il costruttore venga implementato. Tale test potrebbe effettivamente assomigliare a quello presentato, anche se l'implementazione del costruttore avrebbe una logica di validazione pari a zero.

Si noti inoltre che per TDD, si dovrebbe scrivere prima un altro test come

  Assert.Throws<ArgumentException>(() => new Person(Guid.NewGuid(), 
        new DateTime(1572, 01, 01));

prima di aggiungere il controllo per DateTime(1900,01,01)al costruttore.

Nel contesto TDD, il test mostrato ha perfettamente senso.