Одним із прикладів випадку відмови, який ви хочете заздалегідь зафіксувати, є те, що випробовуваний об’єкт використовує шар кешування, але не може зберегти дані, як потрібно. Тоді, якщо ви запитаєте об'єкт, він скаже: "Так, я отримав нове ім'я та адресу", але ви хочете, щоб тест не вийшов, оскільки він насправді не зробив те, що повинен був.
В якості альтернативи (і з увагою на порушення однієї відповідальності), припустимо, потрібно зберігати версію рядка з кодуванням UTF-8 у поле, орієнтоване на байт, але насправді зберігається Shift JIS. Деякі інші компоненти збираються прочитати базу даних і очікують, що вони побачать UTF-8, звідси і вимога. Тоді зворотний проїзд через цей об’єкт повідомить правильне ім’я та адресу, оскільки він перетворить його назад із Shift JIS, але помилка не виявлена вашим тестом. Сподіваємось, це буде виявлено деяким пізнішим інтеграційним тестом, але вся суть тестових підрозділів полягає в тому, щоб рано наздогнати проблеми і точно знати, який компонент несе відповідальність.
Якщо хтось із них не робить того, що належить, то його власний тестовий випадок вийде з ладу, і ми можемо виправити його та запустити тестовий акумулятор знову.
Ви не можете цього припустити, тому що якщо ви не обережні, ви пишете взаємозалежний набір тестів. Значення "це рятує?" test викликає метод тестування, який він тестує, а потім метод завантаження, щоб підтвердити його збереженням. "Це завантажується?" test викликає метод збереження для встановлення тестового кріплення, а потім метод навантаження, який він тестує, щоб перевірити результат. Обидва тести покладаються на правильність методу, який вони не тестують, тобто жоден з них насправді не перевіряє правильність методу, який він тестує.
Розуміння, що тут є проблема, полягає в тому, що два тести, які нібито тестують різні одиниці, насправді роблять те саме . Вони обидва викликають сеттера, за яким йде геттер, а потім перевіряють результат - початкове значення. Але ви хотіли перевірити, що сеттер зберігає дані, а не те, що пара setter / getter працює разом. Тож ви знаєте, що щось не так, просто потрібно розібратися, що і виправити тести.
Якщо ваш код добре розроблений для тестування одиниць, то ви можете принаймні два способи перевірити, чи справді дані зберігалися правильно перевіреним методом:
знущайтеся з інтерфейсу бази даних, а ваш макет записує той факт, що в ньому були викликані належні функції із очікуваними значеннями. Цей тест методом робить те, що йому належить, і є класичним одиничним тестом.
передайте йому фактичну базу даних з точно таким же наміром , щоб записати, чи правильно зберігалися дані. Але замість того, щоб мати глузувальну функцію, яка просто говорить "так, я отримав потрібні дані", ваш тест зчитує з бази даних безпосередньо і підтверджує, що це правильно. Це може бути не найчистішим можливим тестом, тому що цілий механізм баз даних є досить великою справою, щоб написати прославлений макет, з більшим шансом на мене не помітити деяку тонкість, яка робить тестовий пропуск, хоча щось не так (наприклад, я не слід використовувати для читання те саме з’єднання з базою даних, яке було використано для запису, тому що я можу побачити неспроможену транзакцію). Але це перевіряє правильність, і принаймні ви знаєте, що це точно реалізує весь інтерфейс бази даних без необхідності писати макетний код!
Отже, це лише детальна інформація про тестування, чи читаю я дані з тестової бази даних JDBC, чи знущаюся над базою даних. У будь-якому разі суть полягає в тому, що я можу перевірити пристрій краще, виділивши його, ніж можу, якщо я дозволю йому змова з іншими неправильними методами того ж класу, щоб виглядати правильно, навіть коли щось не так. Тому я хочу використовувати будь-який зручний спосіб перевірити, чи зберігаються правильні дані, окрім довіри компоненту, метод якого я тестую.
Якщо ваш код недостатньо розроблений для тестування одиниць, то, можливо, у вас не буде вибору, оскільки об'єкт, метод якого ви хочете перевірити, може не сприймати базу даних як введену залежність. У такому випадку обговорення найкращого способу ізоляції досліджуваного підрозділу перетворюється на дискусію про те, наскільки близько можна дійти до ізоляції досліджуваної одиниці. Однак висновок той самий. Якщо ви зможете уникнути змов серед несправних одиниць, тоді ви це зробите, за умови наявного часу та будь-якого іншого, що ви вважаєте, що було б більш ефективно при пошуку несправностей у коді.