Какова цель Verifiable () в Moq?

Какова цель Verifiable()?

Если я проверю Mock и опущу это, он все равно проверяет SetUp.

Изменить: я использовал VerifyAll(), поэтому все проверялось. После перехода на Verify() проверялись только мои .Verifiable() SetUp.


moq
person Castrohenge    schedule 11.06.2009    source источник


Ответы (2)


ДОБАВЛЕНИЕ: Как указано в другом ответе, цель .Verifiable состоит в том, чтобы включить Setup в набор «отложенных Verify(...) вызовов», которые затем могут быть запущены через mock.Verify().

Разъяснение OP дает понять, что это была цель, и единственная проблема заключалась в том, чтобы выяснить, почему она не работает, но, как подсказал @Liam, ответ действительно должен коснуться и этого: - Ключ варианты использования, насколько я могу судить, следующие:

  • поддержание СУХОСТИ между mock.Setup() и mock.Verify
  • позволяя отключить настройку проверки от самого вызова Verify (например, вы можете настроить его в другом вспомогательном методе)

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

ОРИГИНАЛ: обратите внимание, что там, где это возможно, следует вместо этого следовать макету AAA и, следовательно, следует использовать выполнение явных mock.Verify( expression ) вызовов после завершения работы, а не mock.Setup( ... ).Verifiable() в паре с mock.Verify() или mock.VerifyAll() по возможности (кредит: @kzu).

person Ruben Bartelink    schedule 13.11.2009
comment
Чтобы уточнить: если мне нужен макет, чтобы вернуть что-то в тестируемый код, будет ли это подходящим случаем, когда Setup(...) (в моем разделе аранжировки) и VerifyAll() (в моем разделе assert)? - person Eric Smith; 14.02.2012
comment
@EricSmith Оглядываясь назад, не думаю, что я выразился достаточно сильно. Разделение вашей работы на объединение AAA дает гораздо больше преимуществ, чем чрезмерная концентрация на общих чертах между этапами Arrange и Assert. В 90% случаев можно кое-что извлечь из нюансов того, как вы выражаете вызовы Verify в конце, поэтому вам нужно потратить много времени на оптимизацию для этого, даже если в некоторых случаях это кажется болезненным дублированием. Одна из замечаний, которую manning.com/osherove очень хорошо подчеркивает, заключается в том, что сделать тест понятным для прыгающего человека - это критично - так что придерживайтесь условностей! - person Ruben Bartelink; 15.02.2012
comment
Обычно я не из тех, кто идет против общепринятой мудрости, но я еще не уверен в преимуществах AAA по сравнению с _1 _ / _ 2_ во всех случаях. В моем текущем модульном тесте много Setup(...) вызовов (›30). Можно сопоставить каждый с эквивалентным Verify () для удовлетворения соглашения, но это вызывает большое количество дублирования кода, и его будет сложнее поддерживать и читать по мере роста количества модульных тестов. Я предполагаю, что я действительно спрашиваю, могут ли быть сделаны исключения, если существует большое количество настроек, или избегание Verifiable() является жестким и быстрым правилом? - person Steve Chambers; 08.05.2013
comment
@SteveChambers Ключевым элементом AAA является то, что это не A * - должно быть одно действие и одно утверждение. Итак, хотя вы технически правы, говоря, что это меньше кода для вас, совпадения того, какие из ваших настроек применяются к каким (под) действиям и (под) утверждениям, неизбежно станут минным полем. Так что нет, это не сложно и быстро, но я бы сказал, что предположить, что это даже близко к 50:50, было бы очень плохим советом. (Также обратите внимание, что вам не нужно выполнять настройку, чтобы выполнить проверку, если вы не пытаетесь ввести определенное поведение во время действия, что является еще одним элементом четких тестов) - person Ruben Bartelink; 08.05.2013
comment
Хотя это интересное обсуждение передовой практики модульного тестирования, это на самом деле не отвечает на вопрос. Вопрос был в том, какова цель Verifiable () ?. на который вы сказали, что вам не следует его использовать. Для тех, кто прочитал это, все еще хочет использовать его, хотя (что они имеют право делать), этот ответ на самом деле не помогает. - person Liam; 30.10.2015
comment
@Liam В этом случае ответ - просто проголосовать за ответ Сувеша. Что касается педантики SO, OP спрашивает какова цель, что, на мой взгляд, предполагает, что они могут быть открыты для более широкого ответа только о том, что он связывает лягушку с лягушкой. NB. Прошло не так много времени до этого ответа, что я проделал тот же поиск и оказался в комментариях к ветке репозитория Moq, на которую я ссылался, что заставило меня понять, что я думаю об этом неправильно, что мгновенно обратилось ко мне. таким же образом он, вероятно, разговаривает и с другими - отсюда и принятие и положительные голоса. - person Ruben Bartelink; 30.10.2015
comment
@Liam И это действительно совершенно нормально, что вы по-прежнему убеждены, что это подходящий инструмент для вашей работы - я действительно хочу сказать, что это не одобряется как общий подход к написанию тестов с моками, т. Е. Несмотря на то, что тот факт, что он аккуратно достигает СУХОСТИ между Setup и Verify, что может быть упущено из-за более высокого достижимого выигрыша, только ослабляя ограничение СУХОЙ способом, предложенным AAA и семейством стратегий, которые настоятельно подразумевают - person Ruben Bartelink; 30.10.2015
comment
Да, не поймите меня неправильно, я согласен. Я просто почувствовал, что немного упустил суть вопроса. В любом случае мне это показалось очень интересным! - person Liam; 30.10.2015
comment
@Liam Спасибо за подсказку; Я обновил свой ответ, потому что вы правы в своем изложении. В тот день, когда я отвечал на такие вопросы, я обычно хотел кратко сформулировать атомарный ответ, а затем позволить конкурирующим ответам, таким как другой, заполнить карту. В наши дни (если бы я все еще находил время, чтобы ответить на вопросы), я бы, вероятно, попытался дать более полный ответ, каким он стал в первую очередь. - person Ruben Bartelink; 30.10.2015

Когда метод Verify() вызывается в конце теста, если какое-либо из ожиданий, отмеченных как проверяемые, не было вызвано, то исключение составляет thrown.

VerifyAll() не проверяет достоверность ожиданий.

person Suvesh Pratapa    schedule 11.06.2009
comment
Не могли бы вы рассказать немного подробнее о том, что VerifyAll () не проверяет достоверность ожиданий? - person J.W.; 29.10.2018
comment
@ J.W. Это означает, что VerifyAll проверяет все настройки, не учитывая, были ли они отмечены как проверяемые ожидания. - person phoog; 24.10.2019
comment
Простой и полезный ответ. Спасибо - person netishix; 08.02.2021