Xem thêm nỗ lực của Ron Jeffries để tạo ra bộ giải Sudoku với TDD , rất tiếc là không hoạt động.
Thuật toán đòi hỏi một sự hiểu biết đáng kể về các nguyên tắc thiết kế thuật toán. Với những nguyên tắc này, thực sự có thể tiến hành tăng dần, với một kế hoạch, giống như Peter Norvig đã làm .
Trong thực tế, đối với các thuật toán đòi hỏi nỗ lực thiết kế không tầm thường, hầu như luôn luôn là nỗ lực đó tăng dần trong tự nhiên. Nhưng mỗi "gia tăng", nhỏ bé trong mắt một nhà thiết kế thuật toán, trông giống như một bước nhảy lượng tử (để mượn cụm từ của bạn) cho một người không có chuyên môn hoặc kiến thức tương tự với họ thuật toán cụ thể này.
Đây là lý do tại sao một nền giáo dục cơ bản trong lý thuyết CS kết hợp với nhiều thực hành lập trình thuật toán cũng quan trọng không kém. Biết rằng một "kỹ thuật" cụ thể (các khối thuật toán xây dựng nhỏ) tồn tại là một chặng đường dài hướng tới việc thực hiện những bước nhảy lượng tử gia tăng này.
Tuy nhiên, có một số khác biệt quan trọng giữa tiến bộ gia tăng trong thuật toán và TDD.
Một trong những khác biệt đã được JeffO đề cập : Một thử nghiệm xác minh tính chính xác của dữ liệu đầu ra tách biệt với thử nghiệm khẳng định hiệu năng giữa việc thực hiện khác nhau của cùng một thuật toán (hoặc các thuật toán khác nhau đưa ra cùng một giải pháp).
Trong TDD, người ta thêm một yêu cầu mới dưới dạng thử nghiệm và thử nghiệm này ban đầu sẽ không vượt qua (màu đỏ). Sau đó, yêu cầu được thỏa mãn (màu xanh lá cây). Cuối cùng mã được tái cấu trúc.
Trong phát triển thuật toán, yêu cầu thường không thay đổi. Kiểm tra xác minh tính chính xác của kết quả được viết trước hoặc ngay sau khi hoàn thành dự thảo (rất tự tin nhưng chậm) của thuật toán. Kiểm tra tính chính xác dữ liệu này hiếm khi thay đổi; người ta không thay đổi nó thành thất bại (màu đỏ) như là một phần của nghi thức TDD.
Tuy nhiên, trong khía cạnh này, phân tích dữ liệu khác biệt rõ rệt với phát triển thuật toán, bởi vì các yêu cầu phân tích dữ liệu (cả bộ đầu vào và kết quả mong đợi) chỉ được định nghĩa một cách lỏng lẻo theo cách hiểu của con người. Do đó, các yêu cầu thay đổi thường xuyên ở cấp độ kỹ thuật. Sự thay đổi nhanh chóng này đặt phân tích dữ liệu ở đâu đó giữa phát triển thuật toán và phát triển ứng dụng phần mềm nói chung - trong khi vẫn nặng về thuật toán, các yêu cầu cũng thay đổi "quá nhanh" theo sở thích của bất kỳ lập trình viên nào.
Nếu yêu cầu thay đổi, nó thường yêu cầu một thuật toán khác.
Trong phát triển thuật toán, việc thay đổi (thắt chặt) kiểm tra so sánh hiệu suất thành thất bại (màu đỏ) là ngớ ngẩn - nó không cung cấp cho bạn cái nhìn sâu sắc về các thay đổi tiềm năng đối với thuật toán của bạn sẽ cải thiện hiệu suất.
Do đó, trong phát triển thuật toán, cả kiểm tra tính chính xác và kiểm tra hiệu năng đều không phải là kiểm tra TDD. Thay vào đó, cả hai đều là bài kiểm tra hồi quy . Cụ thể, kiểm tra hồi quy chính xác ngăn bạn thực hiện các thay đổi đối với thuật toán sẽ phá vỡ tính chính xác của nó; kiểm tra hiệu năng ngăn bạn thực hiện các thay đổi đối với thuật toán sẽ làm cho nó chạy chậm hơn.
Bạn vẫn có thể kết hợp TDD như một phong cách làm việc cá nhân, ngoại trừ nghi thức "đỏ - xanh - tái cấu trúc" không thực sự cần thiết và cũng không đặc biệt có lợi cho quá trình phát triển thuật toán.
Tôi sẽ lập luận rằng các cải tiến thuật toán thực sự là kết quả của việc tạo ra các hoán vị ngẫu nhiên (không cần thiết chính xác) cho các sơ đồ luồng dữ liệu của thuật toán hiện tại, hoặc trộn và kết hợp chúng giữa các triển khai đã biết trước đó.
TDD được sử dụng khi có nhiều yêu cầu có thể được thêm dần vào bộ kiểm tra của bạn.
Ngoài ra, nếu thuật toán của bạn dựa trên dữ liệu, mỗi phần dữ liệu thử nghiệm / trường hợp thử nghiệm có thể được thêm dần dần. TDD cũng sẽ hữu ích. Vì lý do này, cách tiếp cận "giống như TDD" của "thêm dữ liệu thử nghiệm mới - cải thiện mã để làm cho nó xử lý dữ liệu này một cách chính xác - tái cấu trúc" cũng sẽ hoạt động cho công việc phân tích dữ liệu kết thúc mở, trong đó các mục tiêu của thuật toán được mô tả bằng con người từ ngữ lập dị và thước đo thành công của nó cũng được đánh giá theo thuật ngữ xác định của con người.
Nó cố gắng dạy một cách để làm cho nó ít áp đảo hơn là cố gắng đáp ứng tất cả (hàng chục hoặc hàng trăm) yêu cầu trong một nỗ lực duy nhất. Nói cách khác, TDD được kích hoạt khi bạn có thể ra lệnh rằng các yêu cầu nhất định hoặc mục tiêu kéo dài có thể tạm thời bị bỏ qua trong khi bạn đang thực hiện một số dự thảo ban đầu về giải pháp của mình.
TDD không thay thế cho khoa học máy tính. Đó là một cái nạng tâm lý giúp các lập trình viên vượt qua cú sốc khi phải đáp ứng nhiều yêu cầu cùng một lúc.
Nhưng nếu bạn đã có một triển khai cho kết quả chính xác, TDD sẽ xem xét mục tiêu đã hoàn thành và mã sẵn sàng được đưa ra (để tái cấu trúc hoặc cho người dùng lập trình viên khác). Theo một cách nào đó, nó khuyến khích bạn không tối ưu hóa sớm mã của mình, bằng cách khách quan đưa ra tín hiệu rằng mã đó "đủ tốt" (để vượt qua tất cả các bài kiểm tra chính xác).
Trong TDD, cũng tập trung vào "các yêu cầu vi mô" (hoặc các phẩm chất tiềm ẩn). Ví dụ: xác nhận tham số, xác nhận, ném và xử lý ngoại lệ, v.v. TDD giúp đảm bảo tính chính xác của các đường dẫn thực thi thường không được thực hiện trong quá trình thực thi phần mềm thông thường.
Một số loại mã thuật toán cũng chứa những điều này; những điều này có thể tuân theo TDD. Nhưng vì quy trình công việc chung của thuật toán không phải là TDD, nên các thử nghiệm như vậy (về xác nhận tham số, xác nhận và ném và xử lý ngoại lệ) có xu hướng được viết sau khi mã thực thi đã được viết (ít nhất là một phần).