Kiểm thử đơn vị cho một thư viện máy tính khoa học

Tôi đã có một chút kinh nghiệm với kiểm thử đơn vị trước đây, trong cái mà tôi gọi (không phải là một cách miệt thị) dự án kỹ thuật phần mềm cổ điển: một MVC, với GUI người dùng, cơ sở dữ liệu, logic nghiệp vụ ở lớp giữa, v.v ... Bây giờ tôi Tôi đang viết một thư viện máy tính khoa học bằng C # (vâng, tôi biết C # quá chậm, sử dụng C, không phát minh lại bánh xe, và tất cả những thứ đó, nhưng chúng tôi có rất nhiều người làm tính toán khoa học trong khoa của tôi trong C #, và chúng tôi sắp xếp cần nó). Đó là một dự án nhỏ, về ngành công nghiệp phát triển phần mềm, bởi vì tôi tự mình viết nó, và thỉnh thoảng có sự giúp đỡ của một vài đồng nghiệp. Ngoài ra, tôi không được trả tiền cho nó, và quan trọng nhất, là một dự án học thuật. Ý tôi là, tôi hy vọng nó sẽ có chất lượng chuyên nghiệp một ngày nào đó, bởi vì tôi đang lên kế hoạch phát triển nguồn mở,

Dù sao, dự án đang trở nên lớn (khoảng 18.000 dòng mã, mà tôi nghĩ là lớn cho dự án của một người), và nó nằm ngoài tầm tay của tôi. Tôi đang sử dụng git để kiểm soát nguồn và tôi nghĩ rằng tôi đã ổn, nhưng tôi đang thử nghiệm như trường cũ, ý tôi là, viết các ứng dụng bảng điều khiển đầy đủ kiểm tra một phần lớn của hệ thống, chủ yếu là vì tôi không biết làm thế nào để thực hiện kiểm tra đơn vị trong kịch bản này, mặc dù tôi cảm thấy đó là điều tôi nên làm. Vấn đề là thư viện chứa hầu hết các thuật toán, ví dụ: thuật toán đồ thị, bộ phân loại, bộ giải số, phân phối ngẫu nhiên, v.v. Tôi chỉ không biết cách chỉ định các trường hợp thử nghiệm nhỏ cho mỗi thuật toán này, và vì nhiều trong số chúng là stochastic Tôi không biết làm thế nào để xác nhận tính đúng đắn. Ví dụ, để phân loại, một số số liệu như độ chính xác và thu hồi, nhưng các số liệu này tốt hơn để so sánh hai thuật toán hơn là đánh giá một thuật toán đơn lẻ. Vì vậy, làm thế nào tôi có thể xác định tính chính xác ở đây?

Cuối cùng cũng có vấn đề về hiệu suất. Tôi biết một loạt các thử nghiệm khác nhau, nhưng hiệu suất là một trong những tính năng quan trọng của một công cụ khoa học, thay vì sự hài lòng của người dùng hoặc các số liệu kỹ thuật phần mềm khác.

Một trong những vấn đề lớn nhất của tôi là với cấu trúc dữ liệu. Thử nghiệm duy nhất tôi có thể đưa ra cho cây kd là một bài kiểm tra căng thẳng: chèn nhiều vectơ ngẫu nhiên và sau đó thực hiện nhiều truy vấn ngẫu nhiên, và so sánh với tìm kiếm tuyến tính ngây thơ. Tương tự cho hiệu suất. Và với tối ưu hóa số, tôi có các chức năng điểm chuẩn mà tôi có thể kiểm tra, nhưng một lần nữa, đây là một bài kiểm tra căng thẳng. Tôi không nghĩ những bài kiểm tra này có thể được phân loại là bài kiểm tra đơn vị và quan trọng nhất là chạy liên tục, vì hầu hết chúng đều khá nặng. Nhưng tôi cũng nghĩ rằng những thử nghiệm này cần phải được thực hiện, tôi không thể chỉ chèn hai yếu tố, bật gốc và vâng, nó hoạt động cho trường hợp 0-1-n.

Vì vậy, cái gì, nếu có, là phương pháp thử nghiệm (đơn vị) cho loại phần mềm này? Và làm cách nào để tổ chức các bài kiểm tra đơn vị và các bài kiểm tra nặng xung quanh chu trình tích hợp mã-xây dựng-cam kết?

Tôi muốn nói rằng tính toán khoa học thực sự khá phù hợp để thử nghiệm đơn vị. Bạn có đầu vào và đầu ra nhất định, các điều kiện trước và sau được xác định rõ ràng có thể sẽ không thay đổi vào mỗi tuần theo ý thích của một số nhà thiết kế và không có yêu cầu UI khó kiểm tra.

Bạn đặt tên cho một số yếu tố có thể gây rắc rối; Dưới đây là những gì để làm về họ:

• thuật toán ngẫu nhiên: có hai khả năng. Nếu bạn thực sự muốn tự kiểm tra ngẫu nhiên, chỉ cần lên lịch một số lượng lớn các lần lặp lại và khẳng định rằng tỷ lệ các trường hợp dự kiến ​​đáp ứng tiêu chí mong muốn, với biên sai số đủ lớn mà thất bại kiểm tra giả sẽ khá hiếm. (Một bộ kiểm tra rằng các tín hiệu không chính xác Phantom lỗi là nhiều tồi tệ hơn một mà không bắt tất cả các khiếm khuyết có thể tưởng tượng.) Ngoài ra, sử dụng một nguồn ngẫu nhiên cấu hình và thay thế đồng hồ hệ thống (hoặc bất cứ điều gì nó là bạn sử dụng) với một nguồn xác định thông qua sự phụ thuộc tiêm để các xét nghiệm của bạn trở nên hoàn toàn có thể dự đoán.
• các thuật toán chỉ được xác định theo độ chính xác / thu hồi: không có gì ngăn bạn đưa vào toàn bộ các trường hợp đầu vào và đo độ chính xác và gọi lại bằng cách thêm tất cả chúng lên; đó chỉ là một câu hỏi về việc bán tự động tạo ra các trường hợp thử nghiệm như vậy một cách hiệu quả để việc cung cấp dữ liệu thử nghiệm không trở thành nút cổ chai đối với năng suất của bạn. Ngoài ra, chỉ định một số cặp đầu vào / đầu ra được chọn một cách thận trọng và khẳng định rằng thuật toán tính toán chính xác đầu vào mong muốn cũng có thể hoạt động nếu thường trình có thể dự đoán được.
• yêu cầu phi chức năng: Nếu đặc điểm kỹ thuật thực sự mang đến cho các yêu cầu không gian / thời gian rõ ràng, sau đó về cơ bản bạn có để chạy toàn bộ dãy đầu vào / đầu ra cặp và xác minh rằng chiếu theo sử dụng tài nguyên xấp xỉ với mô hình sử dụng yêu cầu. Mẹo ở đây là hiệu chỉnh lớp kiểm tra của riêng bạn trước, để bạn không đo được mười vấn đề với các kích cỡ khác nhau mà kết quả là quá nhanh để đo hoặc mất quá nhiều thời gian để chạy bộ kiểm tra trở nên không thực tế. Bạn thậm chí có thể viết một trình tạo trường hợp sử dụng nhỏ để tạo các trường hợp thử nghiệm có kích thước khác nhau, tùy thuộc vào tốc độ của PU đang chạy.
• các bài kiểm tra nhanh và chạy chậm: cho dù đó là bài kiểm tra đơn vị hay tích hợp, bạn thường kết thúc với rất nhiều bài kiểm tra rất nhanh và một vài bài kiểm tra rất chậm. Vì việc chạy thử nghiệm của bạn thường xuyên rất có giá trị, tôi thường đi theo con đường thực dụng và tách mọi thứ tôi có thành một bộ nhanh và chậm, để người nhanh có thể chạy thường xuyên nhất có thể (chắc chắn trước mỗi lần cam kết), và không quan tâm liệu hai bài kiểm tra 'về mặt ngữ nghĩa' có thuộc về nhau hay không.