Testing an object's state at save

Question

I'm looking to write unit tests for a method such as this one:

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;
}

It's a fairly straight-forward method to test. I'm using the Rhino Mocks framework. But one aspect has me questioning myself. I stub the DAO object and its save method, and I'm wondering how deeply I should test that user object that is passed to the save method. Should I assert that every property of that object is as I expect it to be? Or should I only assert that the PasswordQuestion and PasswordAnswer properites have the correct values? The former seems right to me, as I should make sure that only those two properties have been modified, and the others haven't been touched.

I was hoping some people could give their opinions on this. Is there a rule of thumb or pattern to keep in mind for these types of situations?

Answer 1

Warning: personal opinion ahead

Ok, now that that's out of the way.... for me, it comes down to what I need to do to feel that my code properly implements the needed logic. In this case? I'd have two test cases:

• Dealing with ValidateUser returning false
  • Should return false
  • Save should not have been called
• Dealing with ValidateUser returning true
  • Should return true
  • Save should have been called
    • Object passed to save has the modified question and answer
    • No checks of other properties on user object

However, if/when I got a bug filed that affected this part of the code, I'd add whatever (initially failing) tests were needed to cover the bug, fix the bug, and leave the tests.

Answer 2

Since it's so easy to set up a constraint here, why not test it to ensure there are no side-effects to your method?

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