Test de l'état d'un objet à sauver

Question

Je cherche à écrire des tests unitaires pour une méthode telle que celle-ci:

public override bool ChangePasswordQuestionAndAnswer(string username, string password, string newPasswordQuestion, string newPasswordAnswer) 
{ 
    ISPMembershipUserDao userDao = GetISPMembershipUserDao(); 

    if (ValidateUser(username, password)) 
    { 
     SPMembershipUser user = userDao.GetUserByUserName(username); 

     user.PasswordQuestion = newPasswordQuestion; 
     user.PasswordAnswer = newPasswordAnswer; 

     userDao.Save(user); 

     return true; 
    } 

    return false; 
} 

Il est une méthode assez simple pour tester. J'utilise le framework Rhino Mocks. Mais un aspect me pose des questions. Je stub l'objet DAO et sa méthode de sauvegarde, et je me demande combien je devrais tester cet objet utilisateur qui est passé à la méthode de sauvegarde. Devrais-je affirmer que toutes les propriétés de cet objet est comme je l'espère? Ou devrais-je seulement affirmer que les propriétés PasswordQuestion et PasswordAnswer ont les valeurs correctes? Le premier me semble juste, comme je devrais m'assurer que seulement ces deux propriétés ont été modifiées, et les autres n'ont pas été touchées. J'espérais que certaines personnes pourraient donner leur avis là-dessus. Y a-t-il une règle ou un modèle à garder à l'esprit pour ce genre de situation?

Answer 1

Attention: opinion personnelle avant

Ok, maintenant que c'est hors de la voie .... pour moi, cela revient à ce que je dois faire pour me sentir que mon code implémente correctement la logique nécessaire . Dans ce cas? J'ai deux cas de test:

• Faire face à ValidateUser retour faux
  • Si return false
  • Enregistrer ne doit pas avoir été appelé
• Faire face à ValidateUser retour vrai
  • Devrait retourner vrai
  • Save aurait dû être appelé
    • objet passé pour sauver a la question modifiée et répondre
    • Aucun contrôle d'autres propriétés sur l'objet utilisateur

Cependant, si/quand je J'ai eu un bug qui a affecté cette partie du code, j'ajouterais tout ce qui (initialement échouer) des tests ont été nécessaires pour couvrir le bug, corriger le bug, et laisser les tests.

Answer 2

Puisqu'il est si facile de mettre en place une contrainte ici, pourquoi ne pas le tester pour s'assurer qu'il n'y a pas d'effets secondaires à votre méthode?

stubbedUserDao.AssertWasCalled(x => x.Save(null), o => { 
     o.IgnoreArguments(); 
     o.Constraints(Property.AllPropertiesMatch(expectedMatchingUser)); 
    });