Методи тестування програмного забезпечення надзвичайно різноманітні, і чим більше ви будете навчатись про них, ви починаєте бачити безліч різних (а іноді й суперечливих) настанов. Немає жодної «книги», яку можна було б пройти.
Я думаю, що ви потрапили в ситуацію, коли ви побачили вказівки щодо одиничних тестів, які говорять про такі речі
- Кожен тест повинен бути автономним і не впливати на інші тести
- Кожен одиничний тест повинен перевірити одне, і лише одне
- Одиничні тести не повинні потрапляти в базу даних
і так далі. І все це правильно, залежно від того, як ви визначаєте "одиничний тест" .
Я б визначив "тест одиниці" як щось на зразок: "тест, який виконує одну функціональність для однієї одиниці коду, ізольовані від інших залежних компонентів".
Згідно з цим визначенням, те, що ви робите (якщо вам потрібно додати запис до бази даних, перш ніж ви зможете запустити тест), це зовсім не «одиничний тест», а більше того, що зазвичай називають «інтеграційним тестом». (Справжній тест одиниці, за моїм визначенням, не потрапить у базу даних, тому вам не потрібно буде додавати запис перед його видаленням.)
Тест на інтеграцію буде використовувати функціональні можливості, які використовують декілька компонентів (наприклад, інтерфейс користувача та базу даних), а вказівки, які застосовуватимуться до одиничних тестів, не обов'язково стосуються тестів інтеграції.
Як вже згадували інші у своїх відповідях, те, що ви робите, не обов’язково помиляється, навіть якщо ви робите речі, що суперечать деяким настановам одиничного тесту. Натомість спробуйте роздумати про те, що ви насправді випробовуєте в кожному методі тестування, і якщо ви виявите, що для задоволення вашого тесту вам потрібні кілька компонентів, а для деяких компонентів потрібна попередня конфігурація, тоді продовжуйте це робити.
Але найбільше розумійте, що існує багато видів тестів на програмне забезпечення (одиничні тести, системні тести, інтеграційні тести, дослідницькі тести тощо), і не намагайтеся застосовувати вказівки одного типу до всіх інших.