Вы можете изменить класс так, чтобы вы передавали лямбда в класс, а не весь IWorkClass
. Тогда вы сможете хранить и проверять эту фактическую лямбду.
В качестве альтернативы вы можете использовать механизм обратного вызова для фактического вызова лямбды, которая передается в кэш, а затем проверить, что вместо этого макета был вызван IWorkClass.MyWorkMethod
. Это соответствует тому, как кэш и рабочий класс в конечном итоге используются, когда кеш является ценным, поэтому он также может предоставить лучший пример ценного поведения, чем просто тестирование метода в отдельности.
В-третьих, вы можете просто использовать It.IsAny<Func<string, void>>()
и согласиться с тем, что вам придется правильно проверять этот бит (до тех пор, пока его легче понять, чем неправильно, обычно это нормально). Я обычно называю своих делегатов или лямбда-сигнатур, чтобы, возможно, я неправильно понял эту вещь. Это сработает.
В качестве четвертой альтернативы разверните небольшую заглушку кеша, вместо того чтобы использовать фальшивый фреймворк, затем возьмите и вызовите лямбду из этого. Несмотря на то, что мне нравится Moq
и его аналог Java Mockito
, иногда я нахожу, что юнит-тесты гораздо проще читать и поддерживать, когда мы просто признаем, что инструменты не поддерживают то, что мы пытаемся с ними делать. Это всего лишь несколько строк кода, и есть вероятность, что кэш-заглушка будет полезен и для других модульных тестов.