Как правильно делать mock и unit test

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

Теперь это имеет некоторую ценность, потому что вы тестируете какое-то реальное поведение. Конечно, вы также можете просто проверить это напрямую, передав «истина» или «ложь». Вам даже не нужен макет для этого теста. Ожидания от тестирования - это хорошо, но я написал множество подобных тестов и пришел к тому же выводу, что и вы - это просто не так полезно.

Короче говоря, насмешка полезна, когда вы хотите абстрагироваться от внешних факторов, таких как базы данных, вызовы веб-сервисов и т. Д., И вводить известные значения в этот момент. Но напрямую тестировать моки не всегда полезно.

Вы правы: простота сервиса делает эти тесты неинтересными. Только после того, как вы получите больше бизнес-логики в сервисе, вы получите пользу от тестов.

Вы можете рассмотреть несколько таких тестов:

CreateUser_fails_if_email_is_invalid()
CreateUser_fails_if_username_is_empty()

Еще один комментарий: похоже, что ваши методы возвращают логические значения, указывающие на успех или неудачу, похоже на запах кода. У вас может быть веская причина для этого, но обычно вы должны позволить исключениям распространяться. Это также усложняет написание хороших тестов, поскольку у вас возникнут проблемы с определением того, отказал ли ваш метод по «правильной причине», f.x. вы можете написать CreateUser_fails_if_email_is_invalid () - тест следующим образом:

[Test]
public void CreateUser_fails_if_email_is_invalid()
{
    bool result = userSvc.CreateUser(userWithInvalidEmailAddress);
    Assert.That(result, Is.False);
}

и это, вероятно, будет работать с вашим существующим кодом. Использование цикла TDD Red-Green-Refactor могло бы смягчить эту проблему, но было бы даже лучше иметь возможность фактически обнаружить, что метод не удался из-за неверного адреса электронной почты, а не из-за другой проблемы.

Если вы напишете тесты до написания кода, вы получите гораздо больше от модульных тестов. Одна из причин, по которой кажется, что ваши тесты не имеют большого значения, заключается в том, что вы не получаете выгоду от того, что ваши тесты управляют дизайном. Написание тестов после них - это, в основном, просто упражнение на то, чтобы понять, сможете ли вы запомнить все, что может пойти не так. Написание тестов в первую очередь заставляет вас задуматься о том, как вы на самом деле реализуете эти функции.

Эти тесты не так уж интересны, потому что реализуемая функциональность довольно проста. То, как вы собираетесь насмехаться, кажется довольно стандартным - имитируйте вещи, от которых зависит тестируемый класс, а не тестируемый класс. Возможность тестирования (или хорошее понимание дизайна) уже побудила вас реализовать интерфейсы и использовать внедрение зависимостей для уменьшения взаимосвязи. Возможно, вы захотите подумать об изменении обработки ошибок, как предлагали другие. Было бы неплохо узнать, почему, например, для улучшения качества ваших тестов CreateUser не работает. Вы можете сделать это с исключениями или с параметром out (так работает MembershipProvider, если я правильно помню).

Вы сталкиваетесь с вопросом о подходах к тестированию «классический» или «издевательский». Или «проверка состояния» или «проверка поведения», как описано Мартином Фаулером: http://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting

Еще один замечательный ресурс - это книга Джерарда Месароса «Тестовые шаблоны xUnit: рефакторинг тестового кода».