тестирования объекта на сохранить

Question

Я ищу писать тесты для такого метода, как этот:

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

Это довольно прямолинейный метод для тестирования. Я использую рамки Rhino Mocks. Но один аспект заставил меня расспросить себя. Я блокирую объект DAO и его метод сохранения, и мне интересно, как сильно я должен проверять объект пользователя, который передается методу сохранения. Должен ли я утверждать, что каждый объект этого объекта, как я ожидаю? Или я должен только утверждать, что свойства PasswordQuestion и PasswordAnswer имеют правильные значения? Первое кажется мне правильным, поскольку я должен убедиться, что эти два свойства были изменены, а остальные не были затронуты.

Я надеялся, что некоторые люди могут высказать свое мнение по этому поводу. Есть ли правило большого пальца или шаблон, чтобы иметь в виду эти типы ситуаций?

Answer 1

Предупреждение: личное мнение впереди

Хорошо, теперь, что это из пути .... для меня, это сводится к тому, что мне нужно сделать, чтобы чувствовать, что мой код правильно реализует необходимую логику , В этом случае? Я бы два случая испытаний:

• Работа с ValidateUser возвращения ложных
  • Если вернуть ложные
  • Сохранить не должны были под названием
• Dealing с ValidateUser возвращает истину
  • Должно возвращаться true
  • Сохранить должны были названы
    • объекта передан для сохранения имеет модифицированный вопрос и не отвечать
    • Нет проверки других свойств на объекте пользователя

Однако, если/когда я получил ошибку, которая повлияла на эту часть кода, я бы добавил все (первоначально неудачные) тесты, чтобы покрыть ошибку, исправить ошибку и оставить тесты.

Answer 2

Поскольку так легко настроить ограничение здесь, почему бы не протестировать его, чтобы убедиться в отсутствии побочных эффектов для вашего метода?

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