Ортогональність одиничних випробувань порівняно з точністю одиничних випробувань

Я пишу одиничні тести рульової системи для відеоігор. Система має декілька типів поведінки (уникайте цієї області через причину A, уникайте цієї області через причину B, кожен додаючи трохи контексту до карти регіону. Окрема функція потім аналізує карту і створює бажаний рух.

У мене виникають проблеми з вирішенням питання, як написати одиничні тести на поведінку. Як підказує TDD, мене цікавить лише те, як поведінка впливає на бажаний рух. Наприклад, ухилення від причини-A повинно призвести до віддалення від поганої позиції. Мені байдуже насправді, як і чому поведінка додає контексту на карту, лише те, що бажаний рух знаходиться далеко від позиції.

Тож мої тести на кожну поведінку встановлюють поведінку, змушують її записувати на карту, а потім виконує функцію аналізу карти для розробки потрібного руху. Якщо цей рух задовольняє мої характеристики, то я задоволений.

Однак тепер мої тести залежать як від поведінки, що працює правильно, так і від функції аналізу карти, що працює правильно. Якщо функція розбору не вдається, то я отримаю сотні невдалих тестів, а не пару. Багато посібників із написання тестів припускають, що це погана ідея.

Однак якщо я протестую безпосередньо проти результатів поведінки, глузуючи карту, то, напевно, я занадто щільно підключаюся до реалізації? Якщо я можу отримати такий же потрібний рух з карти, використовуючи дещо іншу поведінку, то тести все одно повинні пройти.

Тож зараз я страждаю на когнітивний дисонанс. Який найкращий спосіб структурувати ці тести?

В ідеальному світі ви справді мали б набір ідеально ортогональних одиничних тестів, все на одному рівні абстракції.

У реальному світі у вас зазвичай є тести на багатьох різних рівнях програми, тому часто вищі тести функціонують, функціональність яких вже перевірена спеціальними тестами нижчого рівня. (Багато людей вважають за краще викликати такі підсистеми / тести інтеграції вищих рівнів, а не одиничні тести; проте вони все ще можуть працювати на одній і тій же тестовій структурі, тому з технічної точки зору немає великої різниці.)

Я не думаю, що це погано. Сенс полягає в тому, щоб ваш код був перевірений найкращим чином, який відповідає вашому проекту та вашій ситуації, а не дотримуватися "ідеального способу".

Такого роду тестування тому було винайдено макети. Основна ідея: Ви пишете макет для вашого об'єкта (карта, поведінка, персонаж, ...), потім пишете тести, використовуючи цей макет замість фактичного об'єкта. Люди іноді називають глузуючі заглушки, і я вважаю, що є і інші слова для обох.

У вашому випадку ви пишете макет для карти, коли потрібно перевірити поведінку, та інші макети щодо поведінки, коли ви хочете перевірити карту. Ваші глузування в ідеалі були б набагато простішими, ніж реальна поведінка, з якої ви знущаєтесь, лише включаючи методи або змінні, які вам справді потрібні для цього тесту. Можливо, вам доведеться писати різні макети для кожного тесту, або ви можете повторно використовувати деякі макети. Незалежно від того, вони повинні бути придатними для тестування і не повинні намагатися бути максимально схожими на фактичну поведінку.

Якщо ви включили кілька прикладів карт або поведінки, можливо, хтось може навести приклади макетів, які ви могли написати. Не я, як я ніколи не програмував більш просунуту відео-гру, ніж Понг, і навіть тоді я слідкував за книгою, але, можливо, хтось добре знав і тестування, і розробки ігор.

Я думаю, ти намагаєшся випробувати те, що набагато вищий рівень, ніж одиниця.

Більшість тестів на поведінку потребують певного інтелекту, щоб зрозуміти, чи правильно він поводився. Це неможливо зробити легко за допомогою автоматизованого тестування.