NSubstitute има ли еквивалент на VerifyAll повикването на MOQ? Бих искал да проверя дали всички обаждания, които очаквам да бъдат получени във всички заместители, действително се извикват, в идеалния случай в единичен TearDown метод. В момента проверявам всяко получено обаждане поотделно в тестове, което не е идеално. Като за начало, всички обаждания, които са настроени на заместителя, но които след това всъщност не се извикват, ще се промъкнат в мрежата, ако не са изрично проверени индивидуално.
NSubstitute VerifyAll еквивалент
Отговори (3)
NSubstitute е предназначен за тестове в стил AAA, а не за запис/повтаряне. Като такъв, той не ги поддържа.
person
Daniel Hilgarth
schedule
07.02.2013
Използвам го в стил ААА. Дори следвайки този стил, има стойност да можете да валидирате всички методи, които очаквате да бъдат извикани от вашия заместител, без да се налага изрично да проверявате всеки един. Ако забравите да валидирате един, това малко размива значението на теста.
- person levelnis; 07.02.2013
@levelnis: Само в Record/Replay трябва изрично да посочите всички методи, които ще бъдат извикани от вашия SUT. В AAA не е нужно да правите това, така че няма начин
VerifyAll да работи.
- person Daniel Hilgarth; 07.02.2013
Разбира се, не е нужно да правите това, но без да можете да потвърдите всички обаждания, включително тези, които сте настроили, но сте забравили да премахнете по-късно в резултат на рефакторинг или нещо друго, или защото сте не толкова усърдни в изчистването на очакванията ви, колкото би трябвало, е възможно да напишете тестове за преминаване с извиквания на методи, които се проследяват от заместител, но които всъщност не се извикват. Бих казал, че тези тестове трябва да се провалят. В един идеален свят всички ние бихме били достатъчно усърдни, за да отхвърлим това, но наличието на тази всеобхватна проверка би помогнало с това.
- person levelnis; 07.02.2013
@levelnis: Попитахте дали е възможно с NSubstitute: Не е. Второ, не виждам защо един тест трябва да е неуспешен, защото метод е бил настроен на заместител и SUT не извиква този метод. Ако този метод не е подходящ за вашия тест, няма причина той да се провали. От друга страна, ако този метод е подходящ, вие изрично ще го проверявате и тестът ще се провали, ако преработите SUT, за да не го извиквате, но сте забравили да коригирате теста.
- person Daniel Hilgarth; 07.02.2013
Това е достатъчно честно Даниел. Единствената ми грижа е да поддържам тестовия код възможно най-прост, като гарантирам, че там няма нищо неуместно. Просто трябва да свикна да мисля за конструирането на моите тестове по малко по-различен начин. Благодаря за вашето мнение
- person levelnis; 07.02.2013
@levelnis: Lean тестовете са добро нещо. Но комуникативните тестове са още по-важни. Какво мислите, че съобщава по-добре какво се очаква:
substitute.VerifyAll() или substitute.Received.Foo(42)?
- person Daniel Hilgarth; 07.02.2013
Това, което описвате, е поведението на Strict mock. Строгите подигравки по дефиниция позволяват само неща, които изрично конфигурирате и очаквате. Това създава много крехки тестове, които са склонни да се повреждат много често, тъй като вашият код се променя, следователно използването на стриктни подигравки не се препоръчва и изобщо не се поддържа от по-нови рамки, като NSubstitute или FakeItEasy.
Бих предложил просто да създадете два теста за всеки един от методите, които трябва да проверите: тест, който проверява, че определен метод е извикан, след това друг, който при същия сценарий проверява този друг метод < силна>неизвикана. По този начин, в случай че логиката ви се промени и един от методите бъде извикан/не извикан, когато трябва, ще получите само един счупен тест.
person
Igal Tabachnik
schedule
07.02.2013
Това създава много крехки тестове, които са склонни да се повреждат много често, тъй като вашият код се променя... означава, че строгите подигравки си вършат работата! Те ви насърчават да опростите взаимодействията между обектите, което подобрява стабилността във времето. Те правят това, като подчертават ненужно сложни взаимодействия, които правят тестовете крехки и т.н.
- person J. B. Rainsberger; 07.02.2013
С уважение, не съм съгласен. Ако следвате традиционния начин на TDD, тогава не трябва да разчитате на функция за обхващане на всичко, за да откриете кога потокът се променя, по-скоро добавяте нови тестове, които проверяват нови взаимодействия. Ако добавите ново условно повикване например и един от тестовете, които сте написали преди това, се повреди поради това, можете да го поправите, като добавите новата логика на условието. Представете си, че всички тестове се провалят през цялото време след добавяне на още едно повикване. Ето защо се наричат крехки, тъй като потенциално могат да се счупят след проста промяна, която може да не ви интересува.
- person Igal Tabachnik; 07.02.2013
Не разбирам как вашият коментар се връзва с моя коментар. Не разчитам на функция за обхващане на всичко по начина, по който описвате. Често поправям крехки тестове, като опростявам взаимодействията в производствения код, вместо да правя подигравките по-малко строги. Виждам това като полза от строгите подигравки. Това е моето мнение. Що се отнася до следването на традиционния TDD начин, аз го правя. Помогнах за популяризирането на традиционния начин на TDD. :)
- person J. B. Rainsberger; 28.10.2013
Знам, че това е доста старо и не съм сигурен от коя страна попадам на Loose срещу Strict, но за NSubstitute можете да постигнете това по следния начин (стил xUnit):
Assert.Empty(_logger.ReceivedCalls());
Показва ви всички получени обаждания, които даден макет има, така че можете просто да се уверите, че този номер е 0. Това може да е по-нова функция от преди, но исках да се уверя, че е там! :)
person
Daniel Lorenz
schedule
26.01.2018
ReceivedCalls(): groups.google.com/group/nsubstitute/browse_frm/thread/ Ако имате нужда от това често, вероятно е най-добре да се придържате към Moq или Rhino Mocks. - person David Tchepak schedule 07.02.2013