Xây dựng các thuật toán phức tạp với TDD

Tôi đang cố gắng áp dụng TDD trong thực hành lập trình hàng ngày của mình. Tôi sử dụng nó trong công việc rất hiệu quả, nhưng tôi gặp rắc rối với các dự án cá nhân của mình, nơi tôi đang sử dụng một số thuật toán phức tạp.

Thuật toán cụ thể khiến tôi đặt câu hỏi này là Bộ lọc Kalman mở rộng. Nó đủ phức tạp đến nỗi tôi không tin tưởng vào mã tôi đã viết, nhưng nó đủ đơn giản để khó chia tay.

Tôi có thể viết một bài kiểm tra cho thuật toán với đầu vào và đầu ra dự kiến, nhưng tôi sẽ thực hiện nhiều cú đập và mã hóa shotgun ở giữa vì tôi không tin tưởng vào các bước trung gian đó.

Nếu bạn đã làm việc với các thuật toán phức tạp hợp lý và sử dụng TDD, cách tiếp cận của bạn là gì?

TDD không phải là một thay thế cho thiết kế.

Đây là một quan niệm sai lầm phổ biến về TDD, bằng cách nào đó bạn có thể "phát triển" một thiết kế mạch lạc từ red-green-refactor. Bạn không thể. Bài kiểm tra của bạn vẫn cần được hướng dẫn bởi các kỹ năng thiết kế của bạn.

Nếu bạn đang cố gắng tìm ra những việc cần làm giữa đầu vào và đầu ra của phương thức của bạn đang được kiểm tra, điều đó có thể có nghĩa là bạn đang cố gắng làm quá nhiều trong một phương thức. Hãy suy nghĩ về những gì các bước trung gian nên làm. Viết các bài kiểm tra cho các bước trung gian đó và viết các phương thức vượt qua các bài kiểm tra đó.

Người ta có thể sử dụng TDD cho các thuật toán phức tạp. Viết nhiều bài kiểm tra rõ ràng nhưng có ý nghĩa và sử dụng chúng để thiết kế chương trình của bạn. nếu có ngẫu nhiên được sử dụng trong thuật toán, hãy sử dụng một số loại tiêm phụ thuộc và ngẫu nhiên thử nghiệm riêng biệt. TDD là một trong nhiều phương pháp bạn sẽ sử dụng để viết các thuật toán chất lượng cao: khác là đánh giá mã, ghi nhật ký, v.v.

Tôi có thể viết một bài kiểm tra cho thuật toán với đầu vào và đầu ra dự kiến,

Không viết bài kiểm tra "a" .. TDD không viết một bài kiểm tra tại một thời điểm. Trước tiên, hãy viết nhiều bài kiểm tra để kiểm tra các giới hạn khác nhau và các đầu vào tiêu chuẩn của thuật toán ..

Tôi chưa quen với TDD (đọc: Có lẽ tôi không làm đúng), nhưng có vẻ phù hợp hơn với các thuật toán dễ mô tả, khi bạn có thể dễ dàng suy luận về đầu vào nào khớp với đầu ra nào.

Khi tôi làm nhiều hơn "Tôi không biết kết quả sẽ ra sao" TDD không hữu ích cho tôi. Thay vào đó, những gì tôi làm, tôi sử dụng các khẳng định rất tự do trên các phần nhỏ mà tôi biết làm việc như thế nào cho đến nay. Bằng cách này, tôi không bị mắc kẹt khi cố mã hóa mục tiêu mà tôi không chắc là mục tiêu hợp lệ, nhưng tôi có được sự bảo vệ, định vị các vùng đau đến các phần nhỏ hơn của mã.

Khi thuật toán được sắp xếp cho chính xác (như tôi chắc chắn về ít nhất một số đầu vào-> đầu ra để kiểm tra tại chỗ), sau đó tôi quay lại và viết một bài kiểm tra. Sau đó, an toàn hơn nhiều để quay lại và tái cấu trúc, hoặc tối ưu hóa cho tốc độ hoặc sử dụng tài nguyên.

Tôi muốn nói rằng loại điều này phù hợp hơn với RDD: Phát triển dựa trên việc đọc.

Đây là nơi bạn đọc trong một cuốn sách thuật toán cho một thứ phức tạp như bộ lọc Kalman, sau đó dịch nó thành một triển khai trong môi trường mục tiêu của bạn.

Nhược điểm là làm mọi thứ theo cách đó có nghĩa là bạn không nhận được các trường hợp thử nghiệm miễn phí như một phần của quy trình thiết kế. Mặt khác, một cái gì đó sẽ được biết đến như thế gần như chắc chắn đã có một triển khai hiện có (ví dụ: Commons Math ). Và sau đó, thật khó để sử dụng nó như một lời tiên tri thử nghiệm cho việc thực hiện mới của bạn; tất cả những gì bạn cần lo lắng là tập hợp các trường hợp thử nghiệm của bạn bao gồm tất cả các đường dẫn trong mã của bạn.