Ключова відмінність, на мою думку, полягає в тому, що тести інтеграції виявляють, чи функція працює чи зламана, оскільки вони підкреслюють код у сценарії, близькому до реальності. Вони посилаються на один або кілька програмних методів або функцій і перевіряють, чи діють вони, як очікувалося.
На протилежному, тест Unit тестування один метод заснований на (часто неправильно) припущенні , що інша частина програмного забезпечення працює правильно, тому що він явно знущається кожну залежність.
Отже, коли тест одиниці методу, що реалізує якусь функцію, зелений, це не означає, що функція працює.
Скажіть, у вас є такий спосіб десь такий:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomethingдуже важливий для вашого клієнта: це особливість, єдине, що має значення. Ось чому ви зазвичай пишете специфікацію «Огірок», стверджуючи це: ви хочете перевірити та повідомити, чи функція працює чи ні.
Feature: To be able to do something
In order to do something
As someone
I want the system to do this thing
Scenario: A sample one
Given this situation
When I do something
Then what I get is what I was expecting for
Немає сумнівів: якщо тест пройде, ви можете стверджувати, що ви постачаєте робочу функцію. Це те, що можна назвати Business Value .
Якщо ви хочете написати одиничний тест, DoSomethingвам слід зробити вигляд (використовуючи деякі макети), що решта класів і методів спрацьовують (тобто, що всі залежності, якими використовується метод, правильно працюють) і стверджувати, що ваш метод працює.
На практиці ви робите щось на кшталт:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
return someResults;
}
Ви можете зробити це за допомогою введення залежностей або якогось фабричного методу або будь-якої макетної системи або просто розширити тестований клас.
Припустимо, помилка Log.DoSomething(). На щастя, специфікація Gherkin знайде її, і ваші тести завершені не будуть.
Функція не буде працювати, тому що Logвона зламана, а не тому [Do your job with someInput], що не робить свою роботу. І, до речі, [Do your job with someInput]саме цей метод несе відповідальність.
Крім того, припустимо Log, використовується в 100 інших функціях, в 100 інших методах у 100 інших класах.
Так, 100 функцій не зможуть. Але, на щастя, 100 тестів, що завершуються, провалюються і виявляють проблему. І так, вони говорять правду .
Це дуже корисна інформація: я знаю, що у мене зламаний продукт. Це також дуже заплутана інформація: вона нічого не говорить про те, де проблема. Це передає мені симптом, а не першопричину.
Тим не менше, DoSomethingтест одиниці зелений, тому що він використовує підробку Log, побудовану для того, щоб ніколи не зламатися. І, так: це явно брехня . Це спілкування зламаної функції працює. Чим це може бути корисно?
(Якщо DoSomething()тест блоку не вдався, будьте впевнені: [Do your job with someInput]є деякі помилки.)
Припустимо, це система з розбитим класом:
Один помилка порушить кілька функцій, і кілька тестів на інтеграцію не вдасться.
З іншого боку, та сама помилка порушить лише один тест на одиницю.
Тепер порівняйте два сценарії.
Один і той самий помилка порушить лише один одиничний тест.
- Усі ваші функції використання зламаного
Logкольору - червоного кольору
- Всі ваші тести одиниці зелені, лише тест на одиницю
Log- червоний
Насправді одиничні тести для всіх модулів, що використовують функцію зламаного, зелені, оскільки, використовуючи макети, вони усунули залежності. Іншими словами, вони бігають в ідеальному, повністю вигаданому світі. І це єдиний спосіб виокремити клопів і шукати їх. Тестування блоку означає глузування. Якщо ви не знущаєтесь, ви не проходили тестування.
Різниця
Інтеграційні тести показують, що не працює. Але вони не дають змоги здогадуватися, де може бути проблема.
Експериментальні тести - це єдині тести, які показують, де саме знаходиться помилка. Щоб отримати цю інформацію, вони повинні запустити метод у глузливому середовищі, де всі інші залежності повинні правильно працювати.
Ось чому я вважаю, що ваше речення «Або це просто одиничний тест, який охоплює 2 класи» якимось чином зміщене. Тест одиниці не повинен охоплювати 2 класи.
Ця відповідь є в основному резюме того, що я написав тут: Одиничні тести лежать, тому я їх люблю .
