По сути, вы тестируете здесь то, что методы вызываются, а не работают ли они на самом деле. Это то, что издевательства должны делать. Вместо вызова метода, они просто проверяют, был ли вызван метод, и возвращают все, что есть в выражении Return (). Итак, в вашем утверждении здесь:
Assert.That(result, Is.False, "error message here");
Это утверждение ВСЕГДА будет успешным, потому что ваше ожидание ВСЕГДА вернет false, потому что оператор Return:
userRepo.Expect(repo => repo.CreateUser(theUser)).Return(false);
Полагаю, в этом случае это не очень полезно.
Где насмешка полезна, когда вы хотите, например, сделать вызов базы данных где-то в вашем коде, но вы не хотите фактически вызывать базу данных. Вы хотите притвориться, что база данных была вызвана, но вы хотите настроить поддельные данные для ее возврата, а затем (вот важная часть) протестировать логику, которая делает что-то с поддельными данными, которые вы вернули. В приведенных выше примерах вы пропускаете последний шаг. Представьте, что у вас есть метод, который отображает сообщение для пользователя, в котором говорится, был ли создан новый пользователь:
public string displayMessage(bool userWasCreated) {
if (userWasCreated)
return "User created successfully!";
return "User already exists";
}
тогда ваш тест будет
userRepo.Expect(repo => repo.CreateUser(theUser)).Return(false);
Assert.AreEqual("User already exists", displayMessage(userSvc.CreateUser(theUser)))
Теперь это имеет некоторое значение, потому что вы тестируете какое-то реальное поведение. Конечно, вы также можете просто проверить это напрямую, передав «true» или «false». Вам даже не нужно издеваться над этим тестом. Ожидания по тестированию - это хорошо, но я написал множество подобных тестов и пришел к тому же выводу, к которому вы пришли - он просто не так полезен.
Короче говоря, насмешка полезна, когда вы хотите абстрагироваться от внешних факторов, таких как базы данных, вызовы веб-служб и т. Д., И ввести известные значения в этот момент. Но не всегда полезно тестировать макеты напрямую.