NSubstitute VerifyAll эквивалент

Есть ли у NSubstitute эквивалент вызова VerifyAll MOQ? Я бы хотел убедиться, что все вызовы, которые я ожидаю получить во всех подстановках, на самом деле вызываются, в идеале, в одном методе TearDown . В настоящее время я проверяю каждый полученный вызов индивидуально в тестах, что не является идеальным. Во-первых, любые вызовы, которые настроены на замену, но которые на самом деле не вызываются, проскальзывают через сеть, если они не будут явно проверены индивидуально.

4
nl ja de
Как указано в нескольких ответах, NSUB на самом деле не предназначен для поддержки этого. Если вы действительно заинтересованы, очень неудобным способом его тиражирования является использование ReceivedCalls() : groups.google.com/group/nsubstitute/browse_frm/thread/… Если вам это нужно часто, вам, вероятно, лучше всего придерживаться Moq или Rhino Mocks.
добавлено автор David Tchepak, источник

3 ответы

То, что вы описываете, - это поведение строгого макета. Строгие издевки, по определению, допускают только то, что вы явно настраиваете и ожидаете. Это создает очень хрупкие тесты, которые обычно ломаются очень часто, так как ваш код изменяется, поэтому использование, если строгие издевательства обескуражены, и не поддерживается вообще новыми структурами, такими как NSubstitute или FakeItEasy.

Я бы предложил просто создать два теста для каждого из методов, которые вам нужно проверить: тест, который проверяет, что был вызван какой-то метод , а затем другой, который в том же сценарии проверяет, что другой метод < strong> не был . Таким образом, в случае изменения вашей логики, и один из методов называется/не вызывается, когда это необходимо, вы получите только один тест.

6
добавлено
С уважением, я не согласен. Если вы следуете традиционному методу TDD, вам не следует полагаться на функцию «catch-all», чтобы обнаруживать, когда изменяется поток, вы скорее добавляете новые тесты, которые проверяют новые взаимодействия. Если вы добавите новый условный вызов, например, и один из тестов, которые вы ранее писали из-за этого, вы можете исправить его, добавив новую логику состояния. Представьте, что все тесты не выполнялись все время после добавления еще одного вызова. Вот почему их называют хрупкими, так как они могут потенциально ломаться после простого изменения, которое вам может не понравиться.
добавлено автор Igal Tabachnik, источник
«Это создает очень хрупкие тесты, которые обычно ломаются очень часто, так как ваш код меняется ...» означает, что строгие издевательства выполняют свою работу! Они поощряют вас упрощать взаимодействие между объектами, что улучшает стабильность с течением времени. Они делают это, выделяя ненужные сложные взаимодействия, которые делают тесты хрупкими и т. Д.
добавлено автор J. B. Rainsberger, источник
Я не понимаю, как ваш комментарий связан с моим комментарием. Я не полагаюсь на функцию «catch-all» в том, как вы описываете. Я часто исправляю хрупкие тесты, упрощая взаимодействие в производственном коде, вместо того, чтобы сделать издевательства менее строгими. Я вижу это как преимущество строгих издевательств. Это моя точка зрения. Что касается «следования традиционному методу TDD», я это делаю. Я помог популяризировать «традиционный способ TDD». :)
добавлено автор J. B. Rainsberger, источник

NSubstitute предназначен для тестов стиля AAA, а не для Record/Replay. Таким образом, он не поддерживает их.

5
добавлено
@levelnis: Только в Record/Replay вы должны явно указать все методы, которые будут вызываться вашим SUT. В AAA вам не обязательно это делать, поэтому нет возможности использовать VerifyAll .
добавлено автор Daniel Hilgarth, источник
@levelnis: Вы спросили, возможно ли это с NSubstitute: Это не так. Во-вторых, я не понимаю, почему тест должен завершиться неудачей, потому что метод был установлен на замену, и SUT не вызывает этот метод. Если этот метод не подходит для вашего теста, нет причин для его отказа. С другой стороны, если этот метод релевантен, вы явно проверяете его, а тест будет терпеть неудачу, если вы реорганизовали SUT, чтобы не вызывать его, но забыл настроить тест.
добавлено автор Daniel Hilgarth, источник
@levelnis: Lean тесты - хорошая вещь. Но коммуникативные тесты еще важнее. Как вы думаете, что лучше сообщается, что ожидается: substitute.VerifyAll() или substitute.Received.Foo (42) ?
добавлено автор Daniel Hilgarth, источник
Я использую его в стиле AAA. Даже после этого стиля есть ценность, чтобы иметь возможность проверять все методы, которые вы ожидаете вызывать на вашем подставке, без явного проверки каждого из них. Если вы забыли проверить его, это немного разбавит смысл теста.
добавлено автор levelnis, источник
Конечно, вам не нужно это делать, но не имея возможности проверить все вызовы, в том числе те, которые вы настроили, но забыл удалить позже, в результате рефакторинга или что-то еще, или потому, что вы не так усердно, что вы должны очищать свои ожидания, вы можете написать прохождение тестов с вызовами методов, которые отслеживаются заменой, но которые на самом деле не вызываются. Я бы сказал, что эти тесты не сработают. В идеальном мире мы все будем достаточно усердны, чтобы отрицать это, но эта проверка на все это поможет.
добавлено автор levelnis, источник
Это справедливо, Даниэль. Моя единственная забота заключается в том, чтобы держать тестовый код как можно более сухим, убедившись, что нет ничего, что не имеет значения. Мне просто нужно привыкнуть к размышлению о том, чтобы немного конкретизировать мои тесты. Спасибо за ваш вклад
добавлено автор levelnis, источник

Я знаю, что это довольно старый, и я не уверен, с какой стороны я попадаю в Loose vs Strict, но для NSubstitute вы можете добиться этого следующим образом (стиль xUnit):

Assert.Empty(_logger.ReceivedCalls());

Он показывает, что все полученные вызовы имеют конкретный макет, поэтому вы можете просто убедиться, что это число равно 0. Это может быть более новая функция, чем раньше, но хотелось убедиться, что она там! :)

1
добавлено
QA — вакансии и аналитика рынка вакансий
QA — вакансии и аналитика рынка вакансий
5 668 участник(ов)

Вакансии и поиск работы в сфере QA. Вопросы: @qa_ru Про деньги: @qa_fin При размещении вакансии указывать: - должность - компанию - требования к кандидату - условия и ЗП хэштеги: #город #типзанятости

QA — русскоговорящее сообщество
QA — русскоговорящее сообщество
3 625 участник(ов)

Общаемся про все виды тестирования и его автоматизацию. Без мата, грубостей и провокаций. События: @qaevents Вакансии: @qa_jobs Автоматизаторы: @qa_automation Слухи про компании: @qa_bad_company

QA juniors
QA juniors
2 720 участник(ов)

Добро пожаловать в чат джуниоров QA! Общаемся обо всём, что связано с тестированием и не только :) В чате царит дружественная атмосфера, поэтому общаемся без мата, грубостей. @qa_automation - автоматизация @serious_tester - для тестировщиков и QA

QA - Bad Company!
QA - Bad Company!
2 602 участник(ов)

Позитив и негатив про компании или курсы, куда не стоит идти работать или учиться, а куда стоит. За пиратский контент - бан. @qa_fin о деньгах Русскоговорящее сообщество: @qa_ru Флудилка: @qaFlood Вакансии: @qa_jobs Финансы: @qa_fin

QA — Автоматизация
QA — Автоматизация
2 434 участник(ов)

1. Обсуждение технологий автоматизированного тестирования 2. Помощь начинающим Ru-сообщество: @qa_ru Джуночат: @qajuniors Вакансии: @qa_jobs Финансы: @qa_fin Митапы и события: @qaevents Паблики: @serious_tester, @automation_remarks, @atinfo

QA - Finance
QA - Finance
1 347 участник(ов)

Чат о деньгах тестировщиков. ЗП, релокейты,оферы. @qa_bad_company - обсуждение компаний/курсов и карьерного роста для QA @qa_automation - авто QA Холивары, политика, религия-бан Реклама, спам, оскорбления - бан Для флуда используйте другой чат