tích hợp liên tục cho phần mềm khoa học

Tôi không phải là kỹ sư phần mềm. Tôi là một sinh viên phd trong lĩnh vực khoa học địa chất.

Gần hai năm trước tôi bắt đầu lập trình một phần mềm khoa học. Tôi chưa bao giờ sử dụng tích hợp liên tục (CI), chủ yếu vì lúc đầu tôi không biết nó tồn tại và tôi là người duy nhất làm việc trên phần mềm này.

Bây giờ vì cơ sở của phần mềm đang chạy nên những người khác bắt đầu quan tâm đến nó và muốn đóng góp cho phần mềm. Kế hoạch là những người khác tại các trường đại học khác đang thực hiện bổ sung cho phần mềm cốt lõi. (Tôi sợ họ có thể giới thiệu lỗi). Ngoài ra, phần mềm trở nên khá phức tạp và ngày càng khó kiểm tra hơn và tôi cũng có kế hoạch tiếp tục làm việc với nó.

Vì hai lý do này, giờ đây tôi ngày càng suy nghĩ nhiều hơn về việc sử dụng CI. Vì tôi chưa bao giờ được đào tạo kỹ sư phần mềm và không có ai xung quanh tôi từng nghe về CI (chúng tôi là nhà khoa học, không có lập trình viên), tôi cảm thấy khó khăn khi bắt đầu dự án của mình.

Tôi có một vài câu hỏi mà tôi muốn nhận được một số lời khuyên:

Trước hết là một lời giải thích ngắn về cách thức hoạt động của phần mềm:

• Phần mềm được kiểm soát bởi một tệp .xml chứa tất cả các cài đặt bắt buộc. Bạn khởi động phần mềm bằng cách chuyển đường dẫn đến tệp .xml làm đối số đầu vào và nó chạy và tạo một vài tệp có kết quả. Một lần chạy có thể mất ~ 30 giây.

• Nó là một phần mềm khoa học. Hầu như tất cả các hàm đều có nhiều tham số đầu vào, có kiểu chủ yếu là các lớp khá phức tạp. Tôi có nhiều tệp .txt với các danh mục lớn được sử dụng để tạo các thể hiện của các lớp này.

Bây giờ hãy đến với câu hỏi của tôi:

1. kiểm tra đơn vị, kiểm tra tích hợp, kiểm tra đầu cuối? : Phần mềm của tôi hiện có khoảng 30.000 dòng mã với hàng trăm chức năng và ~ 80 lớp. Tôi cảm thấy lạ khi bắt đầu viết bài kiểm tra đơn vị cho hàng trăm chức năng đã được triển khai. Vì vậy, tôi nghĩ về việc đơn giản là tạo ra một số trường hợp thử nghiệm. Chuẩn bị 10-20 tệp .xml khác nhau và để phần mềm chạy. Tôi đoán đây là những gì được gọi là thử nghiệm đầu cuối? Tôi thường đọc rằng bạn không nên làm điều này, nhưng có lẽ nó vẫn ổn khi bắt đầu nếu bạn đã có một phần mềm hoạt động? Hoặc chỉ đơn giản là một ý tưởng ngu ngốc để cố gắng thêm CI vào một phần mềm đã hoạt động.

2. Làm thế nào để bạn viết kiểm tra đơn vị nếu các tham số chức năng khó tạo ra? giả sử tôi có một hàm double fun(vector<Class_A> a, vector<Class_B>)và thông thường, trước tiên tôi cần đọc nhiều tệp văn bản để tạo các đối tượng kiểu Class_Avà Class_B. Tôi nghĩ về việc tạo ra một số chức năng giả như Class_A create_dummy_object()không đọc trong các tệp văn bản. Tôi cũng nghĩ về việc thực hiện một số loại tuần tự . (Tôi không có kế hoạch kiểm tra việc tạo các đối tượng lớp vì chúng chỉ phụ thuộc vào nhiều tệp văn bản)

3. Làm thế nào để viết bài kiểm tra nếu kết quả rất cao? Phần mềm của tôi sử dụng các mô phỏng monte-carlo lớn và hoạt động lặp lại. Thông thường, bạn có ~ 1000 lần lặp và ở mỗi lần lặp, bạn đang tạo ~ 500-20.000 trường hợp đối tượng dựa trên mô phỏng monte-carlo. Nếu chỉ một kết quả của một lần lặp khác nhau một chút thì toàn bộ các lần lặp lại sắp tới là hoàn toàn khác nhau. Làm thế nào để bạn đối phó với tình huống này? Tôi đoán đây là một điểm lớn so với các bài kiểm tra đầu cuối, vì kết quả cuối cùng rất khác nhau?

Bất kỳ lời khuyên nào khác với CI đều được đánh giá cao.

Kiểm thử phần mềm khoa học rất khó, cả vì vấn đề phức tạp và vì các quy trình phát triển khoa học điển hình (hay còn gọi là hack cho đến khi nó hoạt động, điều này thường không dẫn đến một thiết kế có thể kiểm tra được). Đây là một chút mỉa mai khi xem xét rằng khoa học nên được tái sản xuất. Những thay đổi so với phần mềm thông thường của Cameron không phải là liệu các thử nghiệm có hữu ích hay không (có!), Mà là loại thử nghiệm nào phù hợp.

Xử lý tính ngẫu nhiên: tất cả các lần chạy phần mềm của bạn PHẢI được tái tạo. Nếu bạn sử dụng các kỹ thuật Monte Carlo, bạn phải cung cấp một hạt giống cụ thể cho trình tạo số ngẫu nhiên.

• Thật dễ dàng để quên điều này, ví dụ như khi sử dụng rand()chức năng của C phụ thuộc vào trạng thái toàn cầu.
• Lý tưởng nhất, một trình tạo số ngẫu nhiên được truyền dưới dạng một đối tượng rõ ràng thông qua các hàm của bạn. randomTiêu đề thư viện tiêu chuẩn của C ++ 11 làm cho việc này dễ dàng hơn nhiều.
• Thay vì chia sẻ trạng thái ngẫu nhiên trên các mô-đun của phần mềm, tôi đã thấy hữu ích khi tạo RNG thứ hai được tạo bởi một số ngẫu nhiên từ RNG đầu tiên. Sau đó, nếu số lượng yêu cầu tới RNG của mô-đun khác thay đổi, chuỗi được tạo bởi RNG đầu tiên sẽ giữ nguyên.

Kiểm tra tích hợp là hoàn toàn tốt. Họ rất giỏi trong việc xác minh rằng các phần khác nhau của phần mềm của bạn kết hợp chính xác và để chạy các kịch bản cụ thể.

• Là một cấp độ chất lượng tối thiểu, nó không gặp sự cố, có thể là một kết quả thử nghiệm tốt.
• Để có kết quả mạnh hơn, bạn cũng sẽ phải kiểm tra kết quả dựa trên một số đường cơ sở. Tuy nhiên, các kiểm tra này sẽ phải có phần khoan dung, ví dụ như tài khoản cho các lỗi làm tròn. Nó cũng có thể hữu ích để so sánh thống kê tóm tắt thay vì các hàng dữ liệu đầy đủ.
• Nếu kiểm tra dựa trên đường cơ sở sẽ quá mong manh, hãy kiểm tra xem các đầu ra có hợp lệ không và đáp ứng một số thuộc tính chung. Đây có thể là chung (các vị trí được chọn phải cách nhau ít nhất 2km) hoặc cụ thể theo kịch bản, ví dụ: một vị trí được chọn phải nằm trong khu vực này.

Khi chạy thử nghiệm tích hợp, bạn nên viết một trình chạy thử nghiệm dưới dạng một chương trình hoặc tập lệnh riêng biệt. Trình chạy thử này thực hiện thiết lập cần thiết, chạy tệp thực thi để được kiểm tra, kiểm tra mọi kết quả và dọn sạch sau đó.

Kiểm tra kiểu đơn vị kiểm tra có thể khá khó khăn để chèn vào phần mềm khoa học vì phần mềm chưa được thiết kế cho điều đó. Cụ thể, các bài kiểm tra đơn vị gặp khó khăn khi hệ thống được kiểm tra có nhiều phụ thuộc / tương tác bên ngoài. Nếu phần mềm không hoàn toàn hướng đối tượng, thì nhìn chung không thể giả định / sơ khai những phụ thuộc đó. Tôi thấy tốt nhất là tránh phần lớn các bài kiểm tra đơn vị cho phần mềm như vậy, ngoại trừ các hàm toán học thuần túy và các hàm tiện ích.

Thậm chí một vài bài kiểm tra còn tốt hơn không có bài kiểm tra nào. Kết hợp với việc kiểm tra, nó phải biên dịch lại, đó là một khởi đầu tốt để tích hợp liên tục. Bạn luôn có thể quay lại và thêm các bài kiểm tra sau. Sau đó, bạn có thể ưu tiên các khu vực của mã có nhiều khả năng bị phá vỡ, ví dụ: vì chúng có nhiều hoạt động phát triển hơn. Để xem phần nào trong mã của bạn không nằm trong các thử nghiệm đơn vị, bạn có thể sử dụng các công cụ bao phủ mã.

Kiểm tra thủ công: Đặc biệt đối với các miền có vấn đề phức tạp, bạn sẽ không thể kiểm tra mọi thứ tự động. Ví dụ, tôi hiện đang làm việc về một vấn đề tìm kiếm ngẫu nhiên. Nếu tôi kiểm tra rằng phần mềm của tôi luôn tạo ra kết quả tương tự , tôi không thể cải thiện phần mềm mà không phá vỡ các bài kiểm tra. Thay vào đó, tôi đã làm cho việc kiểm tra thủ công dễ dàng hơn : Tôi chạy phần mềm với một hạt giống cố định và có được một hình dungvề kết quả (tùy thuộc vào sở thích của bạn, R, Python / Pyplot và Matlab đều giúp bạn dễ dàng có được trực quan hóa chất lượng cao của bộ dữ liệu của mình). Tôi có thể sử dụng hình dung này để xác minh rằng mọi thứ đã không đi quá tệ. Tương tự, theo dõi tiến trình của phần mềm của bạn thông qua đầu ra đăng nhập có thể là một kỹ thuật kiểm tra thủ công khả thi, ít nhất là nếu tôi có thể chọn loại sự kiện sẽ được ghi lại.

Tôi cảm thấy kỳ lạ khi bắt đầu viết bài kiểm tra đơn vị cho hàng trăm chức năng đã được triển khai.

Bạn sẽ muốn (thường) viết các bài kiểm tra khi bạn thay đổi các chức năng đã nói. Bạn không cần phải ngồi lại và viết hàng trăm bài kiểm tra đơn vị cho các chức năng hiện có, điều đó sẽ (phần lớn) lãng phí thời gian. Phần mềm này có thể hoạt động tốt. Điểm quan trọng của các thử nghiệm này là đảm bảo những thay đổi trong tương lai không phá vỡ hành vi cũ. Nếu bạn không bao giờ thay đổi một chức năng cụ thể nữa, có lẽ sẽ không bao giờ đáng để dành thời gian để kiểm tra chức năng đó (vì nó hiện đang hoạt động, luôn hoạt động và có khả năng sẽ tiếp tục hoạt động). Tôi khuyên bạn nên đọc hiệu quả với mã kế thừabởi Michael Feathers trên mặt trận này. Anh ta có một số chiến lược chung tuyệt vời để kiểm tra những thứ đã tồn tại, bao gồm các kỹ thuật phá vỡ phụ thuộc, kiểm tra đặc tính (sao chép / dán chức năng đầu ra vào bộ kiểm tra để đảm bảo bạn duy trì hành vi hồi quy), và nhiều hơn nữa.

Làm thế nào để bạn viết kiểm tra đơn vị nếu các tham số chức năng khó tạo ra?

Lý tưởng nhất là bạn không. Thay vào đó, bạn làm cho các tham số dễ tạo hơn (và do đó làm cho thiết kế của bạn dễ kiểm tra hơn). Phải thừa nhận rằng, thay đổi thiết kế cần có thời gian và những tái cấu trúc này có thể khó khăn đối với các dự án cũ như của bạn. TDD (Test Driven Development) có thể giúp với điều này. Nếu các tham số siêu khó tạo, bạn sẽ gặp nhiều khó khăn khi viết bài kiểm tra theo kiểu thử nghiệm đầu tiên.

Trong ngắn hạn, sử dụng giả, nhưng hãy cẩn thận với việc chế giễu địa ngục và các vấn đề đi kèm với chúng trong dài hạn. Tuy nhiên, khi tôi đã trở thành một kỹ sư phần mềm, tôi đã nhận ra hầu như luôn luôn là một mùi nhỏ đang cố gắng giải quyết một số vấn đề lớn hơn và không giải quyết được vấn đề cốt lõi. Tôi thích gọi nó là "gói cỏ", bởi vì nếu bạn đặt một miếng giấy thiếc lên một chút lông chó trên thảm của bạn, nó vẫn còn hôi thối. Những gì bạn phải làm là thực sự đứng dậy, múc phân, và ném nó vào thùng rác, sau đó lấy rác ra. Đây rõ ràng là công việc nhiều hơn và bạn có nguy cơ nhận được một số vấn đề về phân, nhưng tốt hơn cho bạn và sức khỏe của bạn về lâu dài. Nếu bạn cứ quấn những cái phân đó, bạn sẽ không muốn sống trong nhà của mình lâu hơn nữa. Mocks là tương tự trong tự nhiên.

Chẳng hạn, nếu bạn Class_Akhó có thể khởi tạo vì bạn phải đọc trong 700 tệp, thì bạn có thể chế giễu nó. Điều tiếp theo bạn biết, giả của bạn đã hết hạn, và thực tế Class_A có một cái gì đó khác lạ so với giả, và các bài kiểm tra của bạn vẫn vượt qua mặc dù chúng sẽ thất bại. Một giải pháp tốt hơn là chia nhỏ Class_Athành các thành phần dễ sử dụng / kiểm tra hơn và thay vào đó kiểm tra các thành phần đó. Có thể viết một bài kiểm tra tích hợp thực sự đánh vào đĩa và đảm bảo Class_Ahoạt động tổng thể. Hoặc có thể chỉ cần có một hàm tạo để Class_Abạn có thể khởi tạo bằng một chuỗi đơn giản (biểu thị dữ liệu của bạn) thay vì phải đọc từ đĩa.

Làm thế nào để viết bài kiểm tra nếu kết quả rất cao?

Một vài lời khuyên:

1) Sử dụng nghịch đảo (hay nói chung hơn là kiểm tra dựa trên đặc tính). Fft của [1,2,3,4,5]cái gì? Không ý kiến. Có gì ifft(fft([1,2,3,4,5]))? Nên [1,2,3,4,5](hoặc gần với nó, lỗi dấu phẩy động có thể xuất hiện).

2) Sử dụng các xác nhận "đã biết". Nếu bạn viết một hàm xác định, có thể khó có thể nói định thức nào là ma trận 100x100. Nhưng bạn có biết rằng yếu tố quyết định của ma trận danh tính là 1, ngay cả khi đó là 100x100. Bạn cũng biết rằng hàm sẽ trả về 0 trên ma trận không thể đảo ngược (như 100x100 có đầy đủ tất cả 0).

3) Sử dụng các xác nhận thô thay vì các xác nhận chính xác. Tôi đã viết một số mã trước đây đã đăng ký hai hình ảnh bằng cách tạo các điểm kết nối tạo ra ánh xạ giữa các hình ảnh và thực hiện một sự uốn cong giữa chúng để làm cho chúng khớp với nhau. Nó có thể đăng ký ở cấp độ pixel phụ. Làm thế nào bạn có thể kiểm tra nó? Những thứ như:

EXPECT_TRUE(reg(img1, img2).size() < min(img1.size(), img2.size()))

vì bạn chỉ có thể đăng ký trên các phần chồng chéo, hình ảnh đã đăng ký phải nhỏ hơn hoặc bằng với hình ảnh nhỏ nhất của bạn) và cả:

scale = 255
EXPECT_PIXEL_EQ_WITH_TOLERANCE(reg(img, img), img, .05*scale)

vì một hình ảnh được đăng ký với chính nó phải ĐÓNG với chính nó, nhưng bạn có thể gặp nhiều hơn một chút so với các lỗi dấu phẩy động do thuật toán trong tay, vì vậy chỉ cần kiểm tra mỗi pixel có +/- 5% phạm vi hợp lệ (0-255 là một phạm vi phổ biến, thang độ xám). Ít nhất nên có cùng kích thước. Bạn thậm chí có thể chỉ cần kiểm tra khói (tức là gọi nó và đảm bảo nó không bị sập). Nói chung, kỹ thuật này tốt hơn cho các thử nghiệm lớn hơn trong đó kết quả cuối cùng không thể (dễ dàng) tính toán tiên nghiệm để chạy thử nghiệm.

4) Sử dụng HOẶC LƯU TRỮ hạt giống số ngẫu nhiên cho RNG của bạn.

Chạy làm cần phải được tái sản xuất. Tuy nhiên, điều sai lầm là cách duy nhất để có được một lần chạy có thể lặp lại là cung cấp một hạt giống cụ thể cho một trình tạo số ngẫu nhiên. Đôi khi thử nghiệm ngẫu nhiên là có giá trị . Tôi đã thấy một lỗi trong mã khoa học mọc lên trong các trường hợp thoái hóa được tạo ngẫu nhiên . Thay vì luôn gọi hàm của bạn bằng cùng một hạt giống, hãy tạo một hạt giống ngẫu nhiên , sau đó sử dụng hạt giống đó và ghi lại giá trị của hạt giống đó. Theo cách đó, mỗi lần chạy có một hạt giống ngẫu nhiên khác nhau , nhưng nếu bạn gặp sự cố, bạn có thể chạy lại kết quả bằng cách sử dụng hạt giống mà bạn đã đăng nhập để gỡ lỗi. Tôi thực sự đã sử dụng nó trong thực tế và nó đã khắc phục một lỗi, vì vậy tôi đoán rằng tôi đã đề cập đến nó.Nhược điểm: Bạn phải đăng nhập chạy thử. Ưu điểm: Chính xác và sửa lỗi.

HTH.

1. Các loại kiểm tra

   • Tôi cảm thấy lạ khi bắt đầu viết bài kiểm tra đơn vị cho hàng trăm chức năng đã được triển khai

     Hãy nghĩ về nó theo cách khác: nếu một bản vá chạm vào một số chức năng phá vỡ một trong những bài kiểm tra đầu cuối của bạn, làm thế nào bạn sẽ tìm ra cái nào là vấn đề?

     Viết các bài kiểm tra đơn vị cho các chức năng riêng lẻ dễ dàng hơn nhiều so với toàn bộ chương trình. Sẽ dễ dàng hơn nhiều để đảm bảo bạn có phạm vi bảo hiểm tốt của một chức năng riêng lẻ. Việc tái cấu trúc một hàm dễ dàng hơn nhiều khi bạn chắc chắn các bài kiểm tra đơn vị sẽ nắm bắt bất kỳ trường hợp góc nào bạn đã phá vỡ.

     Viết các bài kiểm tra đơn vị cho các chức năng đã tồn tại là hoàn toàn bình thường đối với bất kỳ ai đã làm việc trên một cơ sở mã di sản. Chúng là một cách tốt để xác nhận sự hiểu biết của bạn về các chức năng ở nơi đầu tiên và, sau khi được viết, chúng là một cách tốt để tìm các thay đổi hành vi bất ngờ.

   • Các bài kiểm tra đầu cuối cũng đáng giá. Nếu chúng dễ viết hơn, bằng mọi cách hãy thực hiện trước và thêm các bài kiểm tra đơn vị đặc biệt để bao quát các chức năng mà bạn quan tâm nhất về việc người khác phá vỡ. Bạn không cần phải làm tất cả cùng một lúc.

   • Có, việc thêm CI vào phần mềm hiện có là điều hợp lý và bình thường.

2. Cách viết bài kiểm tra đơn vị

   Nếu đối tượng của bạn thực sự đắt tiền và / hoặc phức tạp, hãy viết giả. Bạn chỉ có thể liên kết các thử nghiệm bằng cách sử dụng các giả lập riêng biệt với các thử nghiệm bằng các đối tượng thực, thay vì sử dụng đa hình.

   Dù sao, bạn cũng nên có một số cách dễ dàng để tạo các thể hiện - một chức năng để tạo các thể hiện giả là phổ biến - nhưng có các bài kiểm tra cho quá trình tạo thực sự cũng hợp lý.

3. Kết quả biến

   Bạn phải có một số bất biến cho kết quả. Kiểm tra những cái đó, thay vì một giá trị số duy nhất.

   Bạn có thể cung cấp một trình tạo số giả ngẫu nhiên nếu mã monte carlo của bạn chấp nhận nó như một tham số, điều này sẽ làm cho kết quả có thể dự đoán được ít nhất là đối với một thuật toán nổi tiếng, nhưng nó dễ vỡ trừ khi nó trả về cùng một số mỗi lần.

1. Không bao giờ là một ý tưởng ngu ngốc để thêm CI. Từ kinh nghiệm tôi biết đây là con đường để đi khi bạn có một dự án nguồn mở nơi mọi người có thể tự do đóng góp. CI cho phép bạn ngăn mọi người thêm hoặc thay đổi mã nếu mã phá vỡ chương trình của bạn, vì vậy nó gần như là vô giá khi có một cơ sở mã hoạt động.

   Khi xem xét các thử nghiệm, bạn chắc chắn có thể cung cấp một số thử nghiệm đầu cuối (tôi nghĩ đó là một danh mục con của các thử nghiệm tích hợp) để đảm bảo rằng dòng mã của bạn đang hoạt động theo cách cần thiết. Bạn nên cung cấp ít nhất một số thử nghiệm đơn vị cơ bản để đảm bảo rằng các hàm xuất ra các giá trị phù hợp, vì một phần của các thử nghiệm tích hợp có thể bù cho các lỗi khác được thực hiện trong quá trình thử nghiệm.

2. Tạo đối tượng thử nghiệm là một cái gì đó khá khó khăn và laboursome thực sự. Bạn đã đúng khi muốn làm đồ vật giả. Các đối tượng này nên có một số giá trị mặc định, nhưng trường hợp cạnh, mà bạn chắc chắn biết đầu ra phải là gì.

3. Vấn đề với những cuốn sách về chủ đề này là bối cảnh của CI (và các bộ phận khác của tín đồ) phát triển quá nhanh, bất cứ điều gì trong một cuốn sách có lẽ sẽ bị lỗi thời vài tháng sau đó. Tôi không biết bất kỳ cuốn sách nào có thể giúp bạn, nhưng Google luôn luôn là vị cứu tinh của bạn.

4. Bạn nên tự chạy thử nghiệm nhiều lần và phân tích thống kê. Bằng cách đó, bạn có thể thực hiện một số trường hợp thử nghiệm trong đó bạn lấy trung bình / trung bình của nhiều lần chạy và so sánh nó với phân tích của bạn, để biết giá trị nào là chính xác.

Một số lời khuyên:

• Sử dụng tích hợp các công cụ CI trong nền tảng GIT của bạn để ngăn chặn mã bị hỏng xâm nhập vào cơ sở mã của bạn.
• dừng việc hợp nhất mã trước khi đánh giá ngang hàng được thực hiện bởi các nhà phát triển khác. Điều này làm cho các lỗi dễ dàng được biết đến hơn và một lần nữa ngăn chặn mã bị hỏng xâm nhập vào cơ sở mã của bạn.

Trong một trả lời trước khi amon đã đề cập đến một số điểm rất quan trọng. Hãy để tôi thêm một số:

1. Sự khác nhau giữa phát triển phần mềm khoa học và phần mềm thương mại

Đối với phần mềm khoa học, tất nhiên trọng tâm là vấn đề khoa học. Các vấn đề được xử lý nhiều hơn về nền tảng lý thuyết, tìm ra phương pháp số tốt nhất, v.v ... Phần mềm chỉ là một, ít nhiều, một phần nhỏ của công việc.

Phần mềm trong hầu hết các trường hợp được viết bởi một hoặc chỉ một vài người. Nó thường được viết cho một dự án cụ thể. Khi dự án kết thúc và mọi thứ được công bố, trong nhiều trường hợp, phần mềm không còn cần thiết nữa.

Phần mềm thương mại thường được phát triển bởi các nhóm lớn trong một khoảng thời gian dài hơn. Điều này đòi hỏi rất nhiều kế hoạch cho kiến ​​trúc, thiết kế, kiểm tra đơn vị, kiểm tra tích hợp, vv Quy hoạch này đòi hỏi một lượng thời gian và kinh nghiệm không đáng kể. Trong một môi trường khoa học, thông thường không có thời gian cho việc đó.

Nếu bạn muốn chuyển đổi dự án của mình thành một phần mềm tương tự như phần mềm thương mại, bạn nên kiểm tra như sau:

• Dou bạn có thời gian và nguồn lực?
• Quan điểm lâu dài của phần mềm là gì? Điều gì sẽ xảy ra với phần mềm khi bạn hoàn thành công việc và rời khỏi trường đại học?

2. Kết thúc để kiểm tra kết thúc

Nếu phần mềm ngày càng phức tạp hơn và một số người đang làm việc với nó, các bài kiểm tra là bắt buộc. Nhưng như amon đã đề cập, việc thêm các bài kiểm tra đơn vị vào phần mềm khoa học là khá khó khăn. Vì vậy, bạn phải sử dụng một cách tiếp cận khác.

Vì phần mềm của bạn đang nhận đầu vào từ một tệp, giống như hầu hết các phần mềm khoa học, nên nó hoàn hảo để tạo một số tệp đầu vào và đầu ra mẫu. Bạn nên chạy các thử nghiệm đó tự động trên mỗi bản phát hành và so sánh kết quả với các mẫu của bạn. Đây có thể là một sự thay thế rất tốt cho các bài kiểm tra đơn vị. Bạn nhận được bài kiểm tra tích hợp theo cách này là tốt.

Tất nhiên, để có được kết quả có thể lặp lại, bạn nên sử dụng cùng một hạt giống cho trình tạo số ngẫu nhiên của mình, như amon đã viết.

Các ví dụ sẽ bao gồm các kết quả điển hình của phần mềm của bạn. Điều này cũng nên bao gồm các trường hợp cạnh của không gian tham số và thuật toán số của bạn.

Bạn nên cố gắng tìm các ví dụ không cần quá nhiều thời gian để chạy, nhưng vẫn bao gồm các trường hợp thử nghiệm điển hình.

3. Tích hợp liên tục

Khi chạy các ví dụ thử nghiệm có thể mất một thời gian, tôi nghĩ rằng tích hợp liên tục là không khả thi. Bạn có thể sẽ phải thảo luận về các phần bổ sung với các đồng nghiệp của bạn. Ví dụ, chúng phải khớp với các phương thức số được sử dụng.

Vì vậy, tôi nghĩ rằng tốt hơn là thực hiện việc tích hợp theo cách được xác định rõ sau khi thảo luận về nền tảng lý thuyết và phương pháp số, kiểm tra cẩn thận, v.v.

Tôi không nghĩ rằng đó là một ý tưởng tốt để có một số loại tự động hóa cho hội nhập liên tục.

Nhân tiện, bạn đang sử dụng một hệ thống kiểm soát phiên bản?

4. Kiểm tra thuật toán số của bạn

Nếu bạn đang so sánh kết quả bằng số, ví dụ như khi kiểm tra kết quả kiểm tra của mình, bạn không nên kiểm tra các số trôi nổi để tìm sự bằng nhau. Luôn luôn có thể có lỗi làm tròn. Thay vào đó, hãy kiểm tra xem chênh lệch có thấp hơn ngưỡng cụ thể không.

Nó cũng là một ý tưởng tốt để kiểm tra các thuật toán của bạn chống lại các thuật toán khác nhau hoặc hình thành vấn đề khoa học theo một cách khác và so sánh kết quả. Nếu bạn nhận được kết quả tương tự bằng hai hoặc nhiều cách độc lập, đây là một dấu hiệu tốt cho thấy lý thuyết của bạn và việc thực hiện của bạn là chính xác.

Bạn có thể thực hiện các thử nghiệm đó trong mã kiểm tra của mình và sử dụng thuật toán nhanh nhất cho mã sản xuất của bạn.

Lời khuyên của tôi sẽ là chọn cẩn thận cách bạn dành những nỗ lực của mình. Trong lĩnh vực của tôi (tin sinh học), các thuật toán hiện đại thay đổi nhanh đến mức tiêu tốn năng lượng vào việc chứng minh lỗi mã của bạn có thể được chi tiêu tốt hơn cho chính thuật toán.

Điều đó nói rằng, những gì có giá trị là:

• nó có phải là phương pháp tốt nhất vào thời điểm đó, về mặt thuật toán?
• dễ dàng chuyển đến các nền tảng tính toán khác nhau (môi trường HPC khác nhau, hương vị hệ điều hành, v.v.)
• sự mạnh mẽ - nó có chạy trên tập dữ liệu MY không?

Bản năng của bạn để xây dựng một cơ sở mã chống đạn là cao cả, nhưng đáng nhớ đây không phải là một sản phẩm thương mại. Làm cho nó dễ mang theo nhất có thể, chống lỗi (cho loại người dùng của bạn), thuận tiện cho người khác đóng góp, sau đó tập trung vào chính thuật toán