Я назвав це питання жартома, бо впевнений, що "це залежить", але у мене є конкретні питання.
Працюючи над програмним забезпеченням, яке має багато глибоких шарів залежності, моя команда звикла використовувати насмішки досить широко, щоб відокремити кожен модуль коду від залежностей під ним.
Тому я був здивований, що Рой Ошерово запропонував у цьому відео, що вам слід використовувати глузування лише щось на зразок 5% часу. Я б здогадався, що ми сидимо десь між 70-90%. Час від часу я також бачив інші подібні вказівки .
Я повинен визначити, що я вважаю двома категоріями "інтеграційних тестів", які настільки виразні, що їм дійсно слід присвоювати різні назви: 1) Тести в процесі роботи, що інтегрують декілька модулів коду, і 2) Тести поза процесом, які говорять до баз даних, файлових систем, веб-служб і т. д. Мене хвилює тип №1, тести, які інтегрують кілька модулів коду в усі процеси.
Значна частина прочитаних вказівок громади говорить про те, що вам слід віддати перевагу великій кількості ізольованих, дрібнозернистих тестових одиниць і невеликій кількості грубозернистих тестів інтеграції з точкою в кінці, оскільки одиничні тести дають точний відгук про те, де саме може бути створено регресії, але грубі тести, які громіздко налаштовувати, насправді підтверджують більшу функціональність системи.
Враховуючи це, видається необхідним досить часто використовувати глузування, щоб виділити ці окремі одиниці коду.
Дано об'єктну модель наступним чином:
... Також врахуйте, що глибина залежності нашого додатка йде набагато глибше, ніж я міг би поміститися на цьому зображенні, так що між 2-4 шаром та 5-13 шаром є кілька шарів N.
Якщо я хочу перевірити просте логічне рішення, яке приймається в блоці №1, і якщо кожна залежність вводиться конструктором в модуль коду, який залежить від нього, так, скажімо, 2, 3 і 4 - конструктор вводиться в модуль 1 в зображення, я б швидше вписав макети 2, 3 і 4 в 1.
В іншому випадку мені знадобиться побудувати конкретні екземпляри з 2, 3 та 4. Це може бути складніше, ніж просто додаткове введення тексту. Часто до 2, 3 і 4 будуть вимоги до конструктора, які можуть бути складними для задоволення, і відповідно до графіка (і відповідно до реальності нашого проекту) мені потрібно будувати конкретні екземпляри від N до 13, щоб задовольнити конструкторів 2, 3 і 4.
Ця ситуація стає більш складною, коли мені потрібно 2, 3 або 4 поводитись певним чином, щоб я міг перевірити просте логічне рішення у №1. Мені може знадобитися зрозуміти та "розумово міркувати" про весь графік / дерево об'єкта відразу, щоб отримати 2, 3 або 4, щоб поводитись необхідним чином. Часто здається, що набагато простіше зробити myMockOfModule2.Setup (x => x.GoLeftOrRight ()) .Повертає (новий Right ()); перевірити, що модуль 1 відповідає так, як очікувалося, коли модуль 2 скаже, що він повинен рухатися правильно.
Якби я перевіряв конкретні екземпляри 2 ... N ... 13 разом, тестові установки були б дуже великими і переважно дублювались. Невдачі тесту можуть не дуже вдало визначити місця відмов регресії. Тести не були б незалежними ( ще одна підтримка ).
Зрозуміло, часто доцільно проводити тестування нижнього шару на основі стану, а не на основі взаємодії, оскільки ці модулі рідко мають будь-яку подальшу залежність. Але здається, що глузування майже необхідне за визначенням, щоб ізолювати будь-які модулі вище самого нижнього.
Враховуючи все це, чи може хтось сказати мені, чого я можу пропустити? Чи наша команда зловживає знущаннями? Або, мабуть, є якесь припущення в типовому керівництві тестування одиниць, що шари залежності в більшості застосунків будуть досить дрібними, що справді розумно перевірити всі кодові модулі, об'єднані разом (що робить наш випадок "особливим")? Або, можливо, інакше, чи наша команда не обмежує адекватно наш обмежений контекст?
Or is there perhaps some assumption in typical unit testing guidance that the layers of dependency in most applications will be shallow enough that it is indeed reasonable to test all of the code modules integrated together (making our case "special")? <- Це.