2009-05-26 7 views
0

Je travaille intensivement sur un projet utilisant Active Directory. J'ai mis en place quelques tests unitaires pour plusieurs choses contre l'AD, dont certains que j'atteins en utilisant des objets mockés, certains que j'atteins à travers de vrais appels contre l'AD.Comment tester unitairement une fonction NextPasswordChangeDate par rapport à Active Directory

Comme l'une des fonctions de mon projet, je dois récupérer un soi-disant "profil utilisateur". Ce profil utilisateur se compose principalement d'attributs simples, tels que "cn", "company", "employeeid", etc. Cependant, une propriété que j'essaie de remplir n'est pas une simple "NextPasswordChangeDate". Pour autant que je sache, la seule façon d'obtenir cela, c'est d'obtenir la valeur maxPwdAge de la politique de domaine et d'utiliser cette information avec pwdLastSet.

Maintenant, ma question: Comment puis-je tester cette unité de manière intelligente? Je suis venu avec trois options, qui ne sont pas géniales:

  1. Utiliser mon propre compte comme compte recherché, trouver la date par d'autres moyens et la coder en dur dans le test unitaire. De cette façon, je peux bien tester mon code unitaire, mais chaque mois, je dois changer le test unitaire, car j'ai changé mon mot de passe.
  2. Utilisez un compte dont le mot de passe n'expire jamais. C'est un peu inutile, parce que je ne peux pas vraiment tester l'exactitude de mon code par cela.
  3. Utilisez un objet simulé et assurez-vous que les appels d'API corrects se produisent. Cette option permet de tester l'exactitude du comportement de la fonction, mais alors la logique testée est en fait dans le test unitaire et donc je ne peux pas être sûr, qu'elle fasse la bonne chose, même si le test est passé.

Lequel des trois proposez-vous? Ou peut-être que vous avez une meilleure option?

Répondre

0

Depuis 1 et 2 le s'appuyer sur AD existant et ayant des valeurs connues me semblent plus comme des tests d'intégration.

Je prends généralement le parti que tout comportement non-déterministe doit être interfacé et mocké si possible (# 3). Comme vous l'avez noté, cela laissera toujours une quantité de code d'implémentation réelle non testable à l'unité, mais qui sera ensuite couverte par vos tests d'intégration exécutés sur un système AD connu.

Related Question/Answer

Questions connexes