Як я можу перевірити евристичний алгоритм?

Скажімо, у нас є алгоритм пошуку маршруту:

def myHeuristicTSP(graph):
    /*implementation*/
    return route

Тепер ми хочемо перевірити це:

class TestMyHeuristicTSP:
    def testNullGraphRaiseValueError(self):
        self.assertRaises(ValueError, myHueristicTSP(None))

    def testSimpleTwoNodeGraphReturnsRoute:
        self.assertEquals(expectedResult, myHeuristicTSP(input))

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

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

Для евристичного алгоритму, який не повинен повертати ідеальне, але "досить хороше" рішення, ви маєте різні тестові випадки та перевірити

1. чи рішення дійсно дійсне? Ви, звичайно, хочете переконатися, що алгоритм пошуку маршруту не повертає шляхи, які неможливі або які насправді не ведуть від початку до кінця. Можливо, ви не зможете довести, що рішення є ідеальним, але ви повинні принаймні мати можливість перевірити, що повернене значення насправді є рішенням.
2. чи рішення «досить добре»? Ви повинні мати деякі вимоги, які визначають, наскільки гірший може бути алгоритм, ніж ідеальне рішення. Ви повинні мати тестові випадки, коли відоме ідеальне рішення (або принаймні рішення, яке вважається достатньо хорошим, щоб використовуватись як еталон порівняння), і підтвердити, що рішення, яке надається алгоритмом, не більше ніж на x% гірше.
3. Чи достатньо швидкий алгоритм? Ви часто використовуєте евристичний підхід, коли припускаєте, що вони компенсують свою недостатню точність, значно швидше. Щоб перевірити це, слід виміряти час їх виконання і переконатися, що вони справді швидші, ніж алгоритм, який отримує точне рішення. Вимірювання часу завжди трохи нечіткі, тому перевищення очікуваного часу виконання повинно бути попередженням, а не помилкою (коли ваш блок тестування блоку дозволяє відрізнятись між попередженнями та помилками).

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

Для створення хороших модульних тестів для будь-якого виду більш складного алгоритму, один на самому справі повинен знати сам алгоритм докладно . Для такої простої евристики, як "сходження на гору", ти зазвичай можеш передбачити результат для невеликих входів. Наприклад, для початкових маршрутів від 3 до 5 балів, якщо вони задані у певному порядку, можна передбачити, що буде. Це залишиться правдою для більшості детермінованих евристичних алгоритмів, про які я знаю, тому, мабуть, це добре місце для початку.

Для складніших алгоритмів та більшого розміру вводу, коли ви просто подаєте вхід в алгоритм і намагаєтеся перевірити вихід, ви насправді більше не робите тест на одиницю, ви робите тест на прийняття чи інтеграцію. Причина, з якої виникають проблеми з "тестовою одиницею" такого альго, полягає в тому, що він, як правило, складається з декількох менших частин (окремих одиниць). Тож для дійсного тестування такого алгоритму вам доведеться визначити ці частини та протестувати їх окремо. Крім того, ви можете використовувати прикриття коду або методи покриття гілок, щоб переконатися, що у вас є достатньо тестових випадків.

Якщо ви не шукаєте одиничні тести, а автоматизовані тести прийняття чи інтеграції, ви можете спробувати те, що пропонував @Phillip в (2) або (3) .