Các chiến lược để thử nghiệm đơn vị và phát triển dựa trên thử nghiệm

Tôi là một người ủng hộ rất lớn cho sự phát triển dựa trên thử nghiệm trong điện toán khoa học. Tiện ích của nó trong thực tế chỉ là đáng kinh ngạc, và thực sự làm giảm bớt những rắc rối kinh điển mà các nhà phát triển mã biết. Tuy nhiên, có những khó khăn cố hữu trong việc kiểm tra các mã khoa học không gặp phải trong lập trình chung, vì vậy các văn bản TDD không hữu ích lắm khi làm hướng dẫn. Ví dụ:

• Nói chung, bạn không biết câu trả lời chính xác cho một vấn đề phức tạp nhất định, vì vậy làm thế nào bạn có thể viết một bài kiểm tra?

• Mức độ thay đổi song song; Gần đây tôi đã gặp một lỗi trong đó sử dụng các tác vụ MPI làm bội số của 3 sẽ thất bại, nhưng bội số của 2 đã hoạt động. Ngoài ra, các khung kiểm tra phổ biến dường như không thân thiện với MPI do bản chất của MPI - bạn phải thực hiện lại một nhị phân thử nghiệm để thay đổi số lượng tác vụ.

• Mã khoa học thường có rất nhiều bộ phận liên kết chặt chẽ, phụ thuộc lẫn nhau và có thể thay thế lẫn nhau. Tất cả chúng ta đều đã thấy mã kế thừa và chúng ta biết nó hấp dẫn đến mức nào khi từ bỏ thiết kế tốt và sử dụng các biến toàn cục.

• Thông thường một phương pháp số có thể là một "thử nghiệm" hoặc người viết mã không hiểu đầy đủ về cách thức hoạt động của nó và đang cố gắng hiểu nó, vì vậy dự đoán kết quả là không thể.

Một số ví dụ về các bài kiểm tra mà tôi viết cho mã khoa học:

• Đối với các nhà tích hợp thời gian, sử dụng ODE đơn giản với một giải pháp chính xác và kiểm tra xem nhà tích hợp của bạn giải quyết nó trong một độ chính xác nhất định và thứ tự chính xác là chính xác bằng cách thử nghiệm với các kích cỡ bước khác nhau.

• Kiểm tra độ ổn định bằng không: kiểm tra xem một phương thức có 0 điều kiện biên / điều kiện ban đầu vẫn ở mức 0.

• Kiểm tra nội suy: đưa ra một hàm tuyến tính, đảm bảo rằng phép nội suy là chính xác.

• Xác thực kế thừa: cô lập một đoạn mã trong ứng dụng cũ được biết là chính xác và kéo một số giá trị riêng biệt ra để sử dụng để thử nghiệm.

Nó vẫn thường xuất hiện rằng tôi không thể tìm ra cách kiểm tra chính xác một đoạn mã nhất định, ngoài việc dùng thử và lỗi thủ công. Bạn có thể cung cấp một số ví dụ về các bài kiểm tra bạn viết cho mã số và / hoặc các chiến lược chung để kiểm tra phần mềm khoa học không?

Phương pháp sản xuất giải pháp .

Xác minh thông qua các nghiên cứu sàng lọc rằng phương pháp đạt được thứ tự lý thuyết về độ chính xác.

Bảo tồn câu trả lời. Tái tạo bit-khôn ngoan và thông thường của các giải pháp.

Bill đã liệt kê một vài phương pháp giải quyết mối quan tâm của bạn.

Giải quyết điểm thứ ba của bạn, không, không có lý do để giới thiệu khớp nối mạnh mẽ giữa các bộ phận. Ngược lại: nếu các chức năng hoặc các lớp của bạn có các giao diện được xác định rõ, việc trao đổi ví dụ là một bộ giải tuyến tính cho một bộ khác hoặc sơ đồ bước thời gian sẽ dễ dàng hơn nhiều. Chỉ cần chống lại nó, và sau đó bạn sẽ có thể kiểm tra các thành phần này một cách riêng biệt. Chúng tôi đã làm điều này với deal.II trong nhiều thập kỷ.

Đến điểm thứ tư của bạn: nếu phương pháp của bạn là một thử nghiệm, thì các thử nghiệm của bạn với phương pháp đó sẽ tạo thành một thử nghiệm. Miễn là bạn không có phân tích, bạn sẽ phải lấy các kết quả kiểm tra này là tốt nhất có sẵn. Nhưng thông thường, bạn có một kỳ vọng ví dụ cho thứ tự của một phương thức, hoặc bạn sẽ biết nó chính xác cho một loại giải pháp nhất định, ví dụ như đa thức đến một mức độ nhất định. Xác minh những điều này nên là một phần trong các thử nghiệm của bạn và khi phân tích được cải thiện, các thử nghiệm có thể được thêm vào.

Gần đây tôi đã tìm thấy luận án này về TDD trong Khoa học tính toán. Tôi chưa đọc nó vì vậy tôi không biết nó có tốt không, nhưng hy vọng nó có thể giúp ích được gì đó.

http://cyber.ua.edu/files/2014/12/u0015_0000001_0001551.pdf