C'est un test valide (bien que plutôt zélé) et je le fais parfois pour tester la logique du constructeur, cependant, comme Laiv l'a mentionné dans les commentaires, vous devriez vous demander pourquoi.
Si votre constructeur ressemble à ceci:
public Person(Guid guid, DateTime dob)
{
this.Guid = guid;
this.Dob = dob;
}
Y a-t-il beaucoup d'intérêt à tester s'il lance? Que les paramètres soient correctement attribués, je peux comprendre, mais votre test est plutôt exagéré.
Cependant, si votre test fait quelque chose comme ceci:
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;
}
Ensuite, votre test devient plus pertinent (car vous lancez des exceptions quelque part dans le code).
Une chose que je dirais, c'est généralement une mauvaise pratique d'avoir beaucoup de logique dans votre constructeur. La validation de base (comme les vérifications nulles / par défaut que je fais ci-dessus) est correcte. Mais si vous vous connectez à des bases de données et chargez les données de quelqu'un, c'est là que le code commence à vraiment sentir ...
Pour cette raison, si votre constructeur mérite d'être testé (car il y a beaucoup de logique), peut-être que quelque chose d'autre ne va pas.
Vous allez presque certainement avoir d'autres tests couvrant cette classe dans les couches de logique métier, les constructeurs et les affectations de variables vont presque certainement obtenir une couverture complète de ces tests. Par conséquent, il peut être inutile d'ajouter des tests spécifiques spécifiquement pour le constructeur. Cependant, rien n'est noir et blanc et je n'aurais rien contre ces tests si je les examinais - mais je me demanderais s'ils ajoutent beaucoup de valeur au-delà des tests ailleurs dans votre solution.
Dans votre exemple:
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;
}
Vous faites non seulement la validation, mais vous appelez également un constructeur de base. Pour moi, cela fournit plus de raisons d'avoir ces tests car ils ont maintenant la logique constructeur / validation divisée en deux classes, ce qui diminue la visibilité et augmente le risque de changement inattendu.
TLDR
Ces tests ont une certaine valeur, mais la logique de validation / affectation est susceptible d'être couverte par d'autres tests dans votre solution. S'il y a beaucoup de logique dans ces constructeurs qui nécessite des tests importants, cela me suggère qu'il y a une mauvaise odeur de code qui se cache là-dedans.