Інші відповіді пояснюють, що таке глузування. Дозвольте мені ознайомитися з вами на різних прикладах . І повірте, насправді це набагато простіше, ніж ти думаєш.
tl; dr Це екземпляр оригінального класу. У нього вводяться інші дані, щоб уникнути тестування деталей, що вводяться, і зосередитись лише на тестуванні деталей реалізації класу / функцій.
Простий приклад:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
Як бачите, я не тестую LineA, тобто я не перевіряю вхідні параметри. Я не перевіряю, чи є num1, num2 цілим числом. Я не маю жодних тверджень проти цього.
Я лише перевіряю, чи дано LineB (моя реалізація ) глузливі значення 1і 5чи працює так, як я очікував.
Очевидно, що в реальному слові це може стати набагато складнішим. Параметри можуть бути спеціальним об'єктом, таким як Person, Address, або деталі реалізації можуть бути більше ніж одиничні +. Але логіка тестування була б однаковою.
Приклад некодування:
Припустимо, ви будуєте машину, яка визначає тип та фірмову назву електронних пристроїв для безпеки аеропорту. Машина робить це, обробляючи побачене своєю камерою.
Тепер ваш менеджер заходить у двері і просить вас перевірити його.
Тоді ви, як розробник, можете або принести 1000 реальних об'єктів, як-от MacBook Pro, Google Nexus, банан, iPad і т.д. перед ним і протестувати і перевірити, чи все працює.
Але ви також можете використовувати знущаються предмети, як ідентичний MacBook Pro (без реальних внутрішніх частин) або пластиковий банан перед ним. Ви можете врятувати себе від інвестицій у 1000 справжніх ноутбуків та гниючих бананів.
Справа в тому, що ви не намагаєтеся перевірити, чи банан підроблений чи ні. Ні тестування, чи ноутбук підроблений чи ні. Все , що ви робите, тестування , якщо ваша машина , коли він бачить банан було б сказати , not an electronic deviceі для MacBook Pro було б сказати: Laptop, Apple. Для машини результат її виявлення повинен бути однаковим для підробленої / глубокої електроніки та реальної електроніки
Логіка, згадана вище, застосовується і для тестування одиниць фактичного коду. Тобто функція повинна працювати однаково з реальними значеннями, які ви отримуєте від реального введення (та взаємодій) або знущаютьсязначення, які ви вводите під час одиничного тестування. І так само, як ви врятуєте себе від використання справжнього банана чи MacBook, за допомогою тестування одиниць (і глузування), ви заощадите себе від необхідності робити щось, що змушує ваш сервер повертати код статусу 500, 403, 200 тощо (примусовий ваш сервер запускає 500 лише тоді, коли сервер не працює, тоді як 200 - коли сервер працює. Важко запустити 100 тестів, орієнтованих на мережу, якщо вам доведеться постійно чекати 10 секунд між переключенням сервера вгору і вниз). Тож замість цього ви вводите / знущаєтесь з відповіді з кодом статусу 500, 200, 403 тощо та випробовуєте свій пристрій / функцію за допомогою введеного / глубокого значення.
Приклад кодування:
Скажімо, ви пишете додаток для iOS та маєте мережеві дзвінки. Ваше завдання - перевірити свою програму. Щоб перевірити / визначити, чи працюють мережеві дзвінки, як очікувалося, НЕ ВАША ВІДПОВІДАЛЬНІСТЬ. Це ще одна відповідальність (команда сервера) перевірити це. Ви повинні усунути цю (мережеву) залежність і все ж продовжувати тестувати весь код, який працює навколо нього.
Мережевий дзвінок може повертати різні коди стану 404, 500, 200, 303 тощо з відповіддю JSON.
Ваш додаток, мабуть, працює для всіх (у разі помилок, ваш додаток повинен видалити очікувану помилку). Що ви робите з глузуванням, ви створюєте "уявні - подібні до реальних" мережеві відповіді (наприклад, код 200 з файлом JSON) і перевіряєте свій код, не "здійснюючи реальний дзвінок у мережі та не чекаючи відповіді вашої мережі". Ви вручну жорсткий код / повертаєте мережеву відповідь на ВСІ види мережевих відповідей і бачите, чи працює ваш додаток, як ви очікували. (ви ніколи не припускаєте / не тестуєте 200 з неправильними даними, тому що це не ваша відповідальність. Ваша відповідальність полягає в тому, щоб перевірити ваш додаток правильним 200, або у випадку 400, 500 ви перевірите, чи ваш додаток видає правильну помилку)
Це створення уявного — схожого на реальне - відоме як глузування.
Для цього ви не можете використовувати свій оригінальний код (у вихідному коді немає попередньо вставлених відповідей, правда?). Ви повинні додати щось до нього, ввести / вставити ті фіктивні дані, які зазвичай не потрібні (або частина вашого класу).
Таким чином, ви створюєте екземпляр оригінального класу і додаєте що завгодно (тут мережевий HTTPResponse, дані АБО у разі відмови, ви передаєте потрібну errorString, HTTPResponse), яка вам потрібна, а потім перевіряєте знущається клас.
Коротше кажучи, глузування - це спростити та обмежити тестування, а також змусити вас годувати те, від чого залежить клас. У цьому прикладі ви уникаєте тестування самих мережевих дзвінків і замість цього перевіряєте, чи працює ваш додаток так, як ви очікуєте, з ін'єкційними виходами / відповідями - глузуючи з класів
Потрібно сказати, що ви перевіряєте кожну мережеву відповідь окремо.
Тепер питання, яке я завжди мав на увазі, було: договори / кінцеві пункти і в основному відповідь JSON моїх API постійно оновлюються. Як я можу написати одиничні тести, які враховують це?
Щоб детальніше зупинитися на цьому: скажімо, модель потребує імені ключа / поля username. Ви перевіряєте це, і ваш тест проходить. Через 2 тижні бекенд змінює ім'я ключа на id. Ваші тести все ще проходять. правильно? чи ні?
Це відповідальність розробника бекенда за оновлення макетів. Чи повинно бути частиною нашої угоди про те, що вони надають оновлені макети?
Відповідь на вищезазначене питання полягає в тому, що: тестові одиниці + ваш процес розробки як розробника на стороні клієнта повинен / захопить застарілий насмішок. Якщо ви запитаєте мене як? добре відповідь:
Наше фактичне додаток не зможе (або не вийде з ладу, але не матиме бажаної поведінки) без використання оновлених API ... отже, якщо це не вдасться ... ми внесемо зміни в наш код розробки. Що знову ж таки призводить до того, що наші тести провалюються .... що нам доведеться виправити. (Насправді, якщо ми хочемо виконати процес TDD правильно, ми не повинні писати жодного коду про поле, якщо ми не пишемо тест для нього ... і побачимо, що він не працює, а потім перейти і написати фактичний код розробки для нього.)
Це все означає, що бекенду не потрібно говорити: «Ей, ми оновили макети» ... це врешті-решт відбувається через розробку / налагодження вашого коду. ّ Тому що це все є частиною процесу розробки! Хоча якщо бекенд надає вам насмішку у відповідь, тоді це простіше.
Моя суть у цьому полягає в тому, що (якщо ви не в змозі автоматизувати отримання оновлених насмішкованих відповідей API), потрібна деяка взаємодія між людьми, тобто ручне оновлення JSON та проведення коротких зустрічей, щоб переконатися, що їх значення актуальні, стануть частиною вашого процесу
Цей розділ був написаний завдяки слабкій дискусії в нашій групі зустрічей CocoaHead
Лише для розробників iOS:
Дуже хороший приклад глузування - це практичні протокольні розмови Наташі Муращев . Просто перейдіть до хвилини 18:30, хоча слайди можуть не синхронізуватися з фактичним відео video
Мені дуже подобається ця частина із стенограми:
Оскільки це тестування ... ми хочемо переконатися, що getфункція з Gettableвиклику викликається, тому що вона може повернутися і функція теоретично може призначити масив продуктів харчування з будь-якого місця . Нам потрібно переконатися, що воно називається;