Тестирование состояния объекта при сохранении - PullRequest
1 голос
/ 23 апреля 2009

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

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 имеют правильные значения? Первое мне кажется правильным, так как я должен убедиться, что только эти два свойства были изменены, а остальные не были затронуты.

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

Ответы [ 2 ]

1 голос
/ 23 апреля 2009

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

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

  • Работа с ValidateUser, возвращающим false
    • Должен вернуть false
    • Сохранить не следовало называть
  • Работа с ValidateUser, возвращающим true
    • Должен вернуть true
    • Сохранить должен был быть вызван
      • Объект, переданный для сохранения, содержит измененный вопрос и ответ
      • Нет проверки других свойств объекта пользователя

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

0 голосов
/ 22 мая 2009

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

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