Làm thế nào để tôi đơn vị kiểm tra một thuật toán heuristic?

Nói rằng chúng tôi có thuật toán tìm tuyến đường của chúng tôi:

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

Bây giờ chúng tôi muốn đơn vị kiểm tra này:

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

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

Câu hỏi là, đối với thuật toán TSP không heuristic, chúng ta có thể đưa ra nhiều biểu đồ khác nhau và kiểm tra xem chúng luôn trả về hoàn toàn con đường ngắn nhất.

Nhưng bởi vì một thuật toán heurtistic, trong khi vẫn mang tính xác định, ít dự đoán hơn, chỉ đơn giản là để hiểu làm thế nào thuật toán có nghĩa là làm việc, và tìm các trường hợp cạnh đó?

Đối với một thuật toán heuristic được cho là không trả về lý tưởng nhưng là một giải pháp "đủ tốt", bạn sẽ có nhiều trường hợp thử nghiệm và kiểm tra

1. Giải pháp có thực sự hợp lệ? Bạn chắc chắn muốn đảm bảo thuật toán tìm tuyến đường của mình không trả về các đường dẫn không thể hoặc không thực sự dẫn từ đầu đến cuối. Bạn có thể không chứng minh được rằng giải pháp là lý tưởng, nhưng ít nhất bạn có thể xác minh rằng giá trị trả về thực sự là một giải pháp.
2. giải pháp "đủ tốt"? Bạn nên có một số yêu cầu xác định thuật toán có thể tệ hơn bao nhiêu so với giải pháp lý tưởng. Bạn nên có các trường hợp thử nghiệm trong đó giải pháp lý tưởng đã biết (hoặc ít nhất là một giải pháp được coi là đủ tốt để được sử dụng làm tiêu chuẩn so sánh) và xác nhận rằng giải pháp được cung cấp bởi thuật toán không quá tệ hơn x%.
3. Là thuật toán đủ nhanh? Bạn thường sử dụng cách tiếp cận heuristic khi bạn cho rằng họ bù đắp cho sự thiếu chính xác của họ bằng cách nhanh hơn nhiều. Để xác minh điều này, bạn nên đo thời gian chạy của chúng và đảm bảo rằng chúng thực sự nhanh hơn thuật toán có được giải pháp chính xác. Các phép đo thời gian chạy luôn mờ một chút, do đó vượt quá thời gian chạy dự kiến ​​sẽ là một cảnh báo, không phải là lỗi (khi khung kiểm tra đơn vị của bạn cho phép khác nhau giữa các cảnh báo và lỗi).

Hầu hết các thuật toán tối ưu hóa (bao gồm cả heuristic) hoạt động trên một số cấu hình (trong ví dụ của bạn là tuyến đường) bằng cách áp dụng các thao tác trên chúng. Bản thân các hoạt động phải đảm bảo rằng chúng chỉ cung cấp các cấu hình hợp lệ, vì vậy trước tiên cần có các thử nghiệm đơn vị cho từng cấu hình. Khi bạn biết chắc chắn thuật toán tối ưu hóa chỉ sử dụng các hoạt động đó, thông thường sẽ không cần kiểm tra tính hợp lệ của kết quả của thuật toán.

Để tạo ra các bài kiểm tra đơn vị tốt cho bất kỳ loại thuật toán phức tạp nào, người ta thực sự phải biết chi tiết về thuật toán . Đối với các heuristic đơn giản như "leo đồi", bạn thường có thể dự đoán kết quả cho các đầu vào nhỏ. Ví dụ: đối với các tuyến ban đầu từ 3 đến 5 điểm, khi được đưa ra theo một thứ tự nhất định, bạn có thể dự đoán điều gì sẽ xảy ra. Điều này sẽ đúng với hầu hết các thuật toán heuristic xác định mà tôi biết, vì vậy đó có lẽ là một nơi tốt để bắt đầu.

Đối với các thuật toán phức tạp hơn và kích thước lớn hơn của đầu vào, khi bạn chỉ đưa đầu vào vào thuật toán và thử kiểm tra đầu ra, bạn thực sự không thực hiện kiểm tra đơn vị nữa, bạn đang thực hiện kiểm tra chấp nhận hoặc tích hợp. Lý do tại sao bạn gặp vấn đề với "kiểm tra đơn vị" một thuật toán như vậy là bởi vì nó thường bao gồm một số ít các bộ phận nhỏ hơn (các đơn vị riêng lẻ). Vì vậy, để thực sự kiểm tra đơn vị một thuật toán như vậy, bạn sẽ phải xác định các phần đó và kiểm tra chúng riêng lẻ. Ngoài ra, bạn có thể sử dụng phạm vi bảo hiểm mã hoặc kỹ thuật bảo hiểm chi nhánh để đảm bảo bạn có đủ trường hợp kiểm tra.

Nếu bạn không tìm kiếm các bài kiểm tra đơn vị, nhưng kiểm tra chấp nhận hoặc tích hợp tự động, bạn có thể thử những gì @Phillip đề xuất trong (2) hoặc (3) .