проблема отладки асинхронной задачи в модульном тесте, потому что она не введена

Question

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

await myRepository.Received(1).Method1(3, null);

Imagine the key method is like this:
public async Task MyKeyMethod(int x) {
if (x == 21) 
      Method1("bla");
if (x == 22)
      Method2("blue");
if (x == 23)
       Method3("ba");
}

Итак, я хочу проверить, что вызов MyKeyMethod (2) действительно переходит в ветку, которая вызывает Method2 («синий»); И я знаю, что могу сделать это чем-то вроде: ожидайте MyKeyMethod.Received (1) .Method2 (22); // Received (1) означает, что метод был вызван один раз.

Вопрос 1: что должно быть 22? Параметр, предоставленный для Method2, или параметр, предоставленный для MyKeyMethod?

Вопрос2: Почему мой код даже не вводит какой-либо метод асинхронной задачи, который у меня есть в обработчике команд (во время отладки)? Есть ли у вас конкретный пример?

Я могу ввести команду шаг за шагом, выполнив что-то вроде:

var cmd = new MyCommand(myObject); // myObject is an object that I mocked earlier (gave it some dummy values for each field)
var commandResponse = await handler.Handle(cmd);
Assert.That(commandResponse.IsSuccessful, Is.True);

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

Вопрос 3. Может ли это быть из-за того, что эти асинхронные методы Task находятся внутри репозитория, который проверяется с помощью

myRepository = Substitute.For<IMyRepository>();

Вопрос 4. Как мне на самом деле не вводить насмешливые методы задач, найденные в репозиториях, которые подвергаются насмешкам?

Answer 1

Я до сих пор осваиваю это, «это» является более широким предметом модульных тестов в NUnit, но, очевидно, моя догадка была верной. Поскольку репозиторий был спровоцирован, я не мог войти и отладить внутри одного из содержащихся в нем методов. Поэтому я использовал реальный (не фальшивый) метод репозитория, который, между прочим, взял в свои конструкторы несколько фальшивых экземпляров других зависимых репозиториев или сервисов, и затем я мог войти в эту задачу. Итак, фактически вместо:

myRepository = Substitute.For<IMyRepository>();

Я пошел и создал настоящий экземпляр, такой как:

var myRepository = new MyRepository>(mockService1, mockRepo2);

, где mockService1 был смоделирован с использованием замены, как указано ранее.

И тогда я смог бы отладить такой метод: myRepository.MyMethod(x), который ранее отладчик не мог проанализировать внутри.

Если у вас есть лучший способ сформулировать мои выводы, во что бы то ни стало, или более полное объяснение, пожалуйста, продолжайте. Спасибо