ADDENDUM: Как указано в другом ответе, цель .Verifiable состоит в том, чтобы зачислить Setup в набор "отложенных Verify(...) вызовов", которые затем можно запускать с помощью mock.Verify().
Пояснения ОП ясно дают понять, что это была цель, и единственной проблемой было выяснить, почему это не сработало, но, как подтолкнул @Liam, ответ должен действительно коснуться этого: - Насколько я вижу, ключевые варианты использования:
- поддержание сухости от
mock.Setup() до mock.Verify
- , позволяющий отключить настройку проверки от самого фактического
Verify вызова (например, вы можете установить его в другом вспомогательном методе)
... и вернемся к моему ответу, который кратко говорит: «будьте осторожны, так как вышеупомянутые профессионалы обычно считаются перевешенными эффектом, который достижение этих целей оказывает на удобочитаемость и ремонтопригодность тестов, которые слишком сильно зависят от таких конструкции "
ОРИГИНАЛ: обратите внимание, что там, где это возможно, следует вместо этого следовать макету AAA и, следовательно, следует делать явные mock.Verify( expression ) вызовы после выполнения работы, а не mock.Setup( ... ).Verifiable() в сочетании с mock.Verify() или mock.VerifyAll() везде, где это возможно (кредит: @ kzu ).