Есть ли способ проверить, что метод set EventWaitHandle был вызван в модульном тесте?

Question

Я попытался использовать фальшивый фреймворк (Moq), но он не работает, потому что Set - не переопределенный метод. Затем я тупо попытался создать свой собственный EventWaitHandle, расширив класс. Не похоже, что есть какой-то момент, который я могу подключить в любом коде, чтобы определить, действительно ли был вызван set.

Я хочу сделать что-то похожее на Timer.Dispose (WaitHandle notifyObject), где кто-то может передать дескриптор ожидания, и я вызову set для него, когда что-то завершится.

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

Answer 1

Это менее чем идеально, но альтернативный подход заключается в создании отдельных Задач для проверки выполнения вызова 'Set', одной для выполнения реальной работы и одной для блокировки на WaitHandle.Затем тест становится случаем ожидания завершения обеих задач (очевидно, добавление тайм-аутов для предотвращения ожидания навсегда!).

Очень грубый пример может быть следующим:

    [Test]
    public void Test_Blocking()
    {
        // Arrange
        var ewh = new EventWaitHandle(false, EventResetMode.ManualReset);
        System.Threading.Tasks.Task<int> blocker = BlockOn(ewh, 0);

        // Act
        System.Threading.Tasks.Task worker = Work(ewh);
        var allTasks = new[] { worker, blocker };
        while (!allTasks.All(t => t.IsCompleted))
        {
            // spin
        }

        // Assert            
        Assert.That(blocker.Result, Is.EqualTo(1));
    }

    private static System.Threading.Tasks.Task<int> BlockOn(EventWaitHandle waitHandle, int counter)
    {
        return System.Threading.Tasks.Task.Factory.StartNew<int>(() =>
        {
            waitHandle.WaitOne();
            return counter + 1;
        });
    }

Answer 2

К сожалению, это невозможно. Тем не менее, вы делаете это правильно - устранение многопоточных аспектов кода, позволяющих тестам запускать однопоточные. Затем Tests проверяет, что были вызваны правильные методы (в данном случае Set).

Хотелось бы, чтобы .NET-инфраструктура была больше разработана с учетом тестов, позволяющих нам высмеивать этот тип метода, позволяя классу реализовать простой интерфейс.

Я был в такой же ситуации с этим точным методом, а также с некоторыми другими, у которых нет интерфейса. В конце концов я закончил Upp либо A) писать обертку B) не писать тесты.