C# Mocking Framework - просто с информативными исключениями

До сих пор я использовал NUnit.Mocks, чтобы изолировать свои классы, но меня раздражает отсутствие обратной связи, которую он мне дает. Так что я искал альтернативы, но ничего не получил.

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

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

Из того, что я собрал, они кажутся одними из самых популярных. Прежде чем я пойду и попробую каждый там, я хотел бы попросить вас людей для предложений...

Что я ищу:

  • Простой дизайн Я не хочу запоминать 100 различных утверждений, и какое из них использовать, в зависимости от того, имеет ли мой метод возвращаемое значение или нет, имеет ли мое свойство и геттеры, и сеттеры, или только один из них, будь то полная луна или нет, и т. Д....
  • Разработать обратную связь. Если мой тест не пройден, я хочу знать, какой вызов метода отсутствовал или слишком много. Я хочу знать, какой звонок имел неправильные аргументы. Так далее...

Мой фон - C# 2.0. Я все еще не знаком с концепциями новых версий.NET. Таким образом, структура, которая не требует этих вещей, будет бонусом.

Спасибо.

Edit: я наконец понял, почему мои тесты Moq не работали. Это не имело никакого отношения к Moq, и сейчас я оцениваю его дальше. Выглядит очень хорошо до сих пор...

Источник

2 ответа

Решение

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

Какие у вас проблемы со свойствами? Чтобы издеваться над возвращением значения из свойства, это просто

mock.Setup(foo => foo.Name).Returns("bar")

Простой дизайн

Moq имеет свободный интерфейс, и код может быть действительно выразительным и довольно красивым. Например:

  1. Инъекция насмешек в объект

    mockView = new Mock<IView>();
mockModel = new Mock<IModel>();
realPresenter = new Presenter(mockView.Object, mockModel.Object);

  2. Тестирование поведения Presenter, реагирующего на событие View

    mockView.Raise(v => v.SomeEvent += null, EventArgs.Empty);
mockModel.Verify(m => m.DoSomething());

Разработка обратной связи

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

Сбой теста "MyProject.MyTest": Moq.MockException: Ожидаемый вызов для макета хотя бы один раз, но он никогда не выполнялся: v =>>v.DoSomething ("Something")> Не настроены настройки.

Выполненные вызовы: View.DoSomething ("SomethingElse") в Moq.Mock.ThrowVerifyException(ожидается MethodCall, IEnumerable1 setups, IEnumerable1 actualCalls, выражение Expression, Times times, Int32 callCount) в Moq.Mock.VerifyCalls(Interceptor targetInterceptor, ожидаемый MethodCall, выражение Expression, Times times) в Moq.Mock.Verify [T] (Mock mock, Expression1 expression, Times times, String failMessage) at Moq.Mock1.Verify (Expression`1 выражение) MyTest.cs(118,0):

Moq Quickstart очень хорошо составлен и был единственным справочным материалом, который мне был нужен до сих пор.

Источник

FakeItEasy был разработан с простотой (открываемостью), а также очень важна обратная связь как две основные цели дизайна с нуля.

Другой главной целью проекта была читаемость тестов.

Вы говорите, что не хотите помнить 100 разных утверждений? Хорошо, хорошо, FakeItEasy использует не больше, чем вы можете рассчитывать на пальцы одной из ваших рук.

Например, настройка и утверждение выполняются с помощью одного и того же оператора:

// Creating a fake
var foo = A.Fake<IFoo>();

// Configuration
A.CallTo(() => foo.Bar()).Returns("a value");

// Assertion
A.CallTo(() => foo.Bar()).MustHaveHappened();
Источник
Другие вопросы по тегам