Мені потрібно трохи пограти в захисника чортів, оскільки я не можу добре відстояти це через брак досвіду. Ось угода, я концептуально розумію відмінності між тестуванням одиниць та інтеграційним тестуванням. Якщо спеціально зосередитись на методах збереження та сховищі, одиничний тест використовує макет, можливо, через рамку на зразок Moq, щоб стверджувати, що скажімо, що шуканий порядок був повернутий, як очікувалося.
Скажімо, я створив такий блок тесту:
[TestMethod]
public void GetOrderByIDTest()
{
//Uses Moq for dependency for getting order to make sure
//ID I set up in 'Arrange' is same one returned to test in 'Assertion'
}
Тож якщо я встановив, OrderIdExpected = 5і мій об’єкт повернеться, 5як ідентифікатор, мій тест пройде. Я розумію. Я підрозділив тест коду, щоб переконатися, що мої кодові заготовки повертають очікуваний об'єкт та ідентифікатор, а не щось інше.
Я отримаю такий аргумент:
"Чому б просто не пропустити одиничні тести і зробити тести інтеграції? Це тестування процедури, що зберігається в базі даних, і ваш код разом, що важливо. Здається, занадто багато додаткової роботи, щоб мати тести на одиницю та інтеграційні тести, коли в кінцевому підсумку я хочу знати, чи викликає база даних і код працює. Я знаю, що тести займають більше часу, але їх потрібно запускати і перевіряти незалежно, тому мені здається безглуздим і те, і інше. Просто перевіряйте те, що має значення ".
Я можу захистити це з визначенням підручника, як-от: "Ну це тест на інтеграцію, і нам потрібно перевірити код окремо як одиничний тест, і, yada, yada, yada ..." Це випадок, коли пуристичне пояснення практики проти реальності втрачається. Іноді я стикаюся з цим, і якщо я не можу захистити міркування, що стоять за кодом тестування одиниці, який, зрештою, покладається на зовнішні залежності, я не можу скласти для цього справи.
Будь-яка допомога з цього питання дуже вдячна, дякую!