Как автоматически отключать зависимости при тестировании функции рецепта

#c# #unit-testing #f#

#c# #модульное тестирование #f#

Вопрос:

У меня есть функция foo(), которая, в свою очередь, вызывает функцию bar() . Как я могу подтвердить, что bar действительно вызывается?

Пример метода сложной бизнес-логики для тестирования:

 class Car
{
  IStarter starter
  IKeyhole keyhole
  IBrakePedal pedal
  Drive()
  {
    keyhole.InsertKey()
    keyhole.RotateToStart()
    starter.TurnEngineOver()

    ...

    if (pedal.Pressed)
      this.SlowDown()
  }
}
  

У меня есть метод, который объединяет 6 внешних зависимостей (интерфейсы с методами) и запускает их в последовательности, порядок не важен. Я хотел бы убедиться, что каждый из них был вызван. В другом тесте я хотел бы настроить условные обозначения и убедиться, что было вызвано подмножество.

В C # с Moq у меня есть полная страница установочного кода.

Вот что я хотел бы увидеть в своем модульном тестировании:

 let `check that brake pedal slows down car` =
   let car = new Car()
   car.pedal.Pressed <- true
   car.Drive()
   car.SlowDown |> wasCalled
  

Остальное должно быть выведено из использования. У меня есть реальная необходимость уменьшить шум в тестах.

Комментарии:

1. вы имеете в виду, как при проверке покрытия кода?

2. Итак … вы рассматривали возможность использования инструмента покрытия кода?

3. знаете ли вы о макетах / заглушках?

4. Кажется, у вас довольно четкая картина… Можете ли вы расширить эту идею? может быть, какой-то псевдокод?

5. Может быть, вы ищете какое-нибудь тестирование F # в стиле BDD? Вы видели TickSpec? tickspec.codeplex.com

Ответ №1:

Самое близкое, что я знаю к тому, что вы хотите, — это AutoMockingContainer .

В двух словах, это контейнер IoC, который предоставляет вам Car со всеми IStarter, IKeyhole, IBrakepedal, отключенными и подключенными к экземпляру Car, без явной регистрации любого из них. Затем вы продолжаете устанавливать свои ожидания как обычно (в вашем случае был вызван «car.slowledge()»), затем вызываете тестируемый метод.

Специфика зависит от используемого контейнера IoC и макетной структуры. Оригинальная версия была написана с помощью Windsor и старой версии Rhino Mocks, но теперь есть AMC для StructureMap, Ninject, Autofac Moq и т. Д.

Вы могли бы начать с одного из них и обернуть его, чтобы сделать его более идиоматичным в F #.

недостатки у него есть , это не то, что я бы рекомендовал использовать «по умолчанию».

Комментарии:

1. Я на стороне Дерика Бейли. Мы покрываем кучу кода модульными тестами, не обращая внимания на грубое ошибочное количество связей.