Làm thế nào để một đơn vị thử nghiệm trong một công cụ trò chơi?

Thật xấu hổ, tôi chưa bao giờ viết một bài kiểm tra đơn vị thích hợp, chỉ những chương trình kiểm tra nhỏ không có tổ chức mà sau đó tôi sẽ loại bỏ sau khi bài kiểm tra thành công. Tôi thực sự không có ý tưởng rõ ràng về cách kiểm tra đơn vị nên được thực hiện trong một dự án trò chơi. (Ngôn ngữ của tôi là C ++.)

Tôi có nên có một dự án riêng cho từng hệ thống con trong công cụ của mình và thử nghiệm liên quan với nó, và sau đó có một dự án / giải pháp lớn hơn để xây dựng công cụ thực tế không? Nói ví dụ tôi có eventmô-đun trong động cơ của tôi; Tôi nên xử lý như thế nào?

Trước tiên, bạn cần một khung kiểm tra đơn vị. Trước đây tôi đã từng sử dụng UnitTest ++ và Google Test . Cái trước rất nhẹ và cái sau thì nổi bật hơn nhưng có phần cồng kềnh hơn. Nó tích hợp tốt với Google Mock nếu bạn cần thứ đó. Tất nhiên có nhiều tùy chọn khác: xem danh sách này (của tác giả cuối cùng của UnitTest ++) và Wikipedia chẳng hạn.

Kiểm thử đơn vị là về việc viết các thử nghiệm tập trung để nhấn mạnh các bit mã độc lập ("đơn vị") bị cô lập cụ thể theo các kịch bản khác nhau. Mặc dù trong một số trường hợp, bạn có thể kiểm tra mọi thứ, nhưng thường không thực tế để đạt được phạm vi bao phủ 100% và đặc biệt là trong các trò chơi, có thể khá khó khăn - không thể tranh cãi liệu việc kiểm tra đơn vị đầu ra của trình kết xuất của bạn có ý nghĩa, hữu ích hay không một bài kiểm tra đơn vị "thật" bất kể

Điều quan trọng cần nhớ là mọi thử nghiệm (tự động) đều tốt hơn so với không thử nghiệm (tự động). Vì vậy, bạn không nên nhấn mạnh quá nhiều vào thực tế rằng các bài kiểm tra của bạn không phải là "bài kiểm tra đơn vị thực sự" và tự hào rằng bạn chỉ đơn giản là có bài kiểm tra. Các khung kiểm tra đơn vị thường hữu ích cho việc xây dựng các thử nghiệm lỏng lẻo hơn, "không phải đơn vị" cũng vì chúng bao gồm chức năng cho các thử nghiệm đóng gói và báo cáo các lỗi không thống nhất.

Tôi sẽ khuyến khích bạn phục hồi các thử nghiệm cũ của mình và xây dựng chúng thành một dự án thử nghiệm bằng một trong các khung có sẵn - thứ gì đó bạn có thể dễ dàng chạy theo thời gian (hoặc tự động như một phần của bản phát hành hoặc tích hợp) chạy tất cả bài kiểm tra của bạn. Viết các bài kiểm tra mới cho các đoạn mã vì rõ ràng chúng sẽ hữu ích cho bạn, ví dụ nếu bạn phát hiện ra một lỗi tinh vi mà bạn có thể đã phát hiện với một bài kiểm tra, bạn có thể thêm một bài kiểm tra để nắm bắt bất kỳ hồi quy nào bạn có thể thực hiện trong tương lai.

Bạn có thể sẽ thấy rằng phần lớn là mã tiện ích cấp thấp hơn của bạn có thể tuân theo thử nghiệm đơn vị, trong các trò chơi. Điều đó tốt - đó là mã nền tảng có thể làm xáo trộn rất nhiều lớp cao hơn nếu nó bị phá vỡ.

Bạn sẽ không đến luyện ngục của lập trình viên vì không có bài kiểm tra cho mọi chức năng nhỏ và cổng logic trong cơ sở mã của bạn, vì vậy đừng dành nhiều thời gian hơn bạn cần để viết bài kiểm tra. Nếu bạn phải suy nghĩ nhiều hơn hoặc dành nhiều thời gian hơn để viết các bài kiểm tra cho một mô-đun so với việc bạn đưa tác giả vào mô-đun ngay từ đầu, bạn có thể sẽ lãng phí thời gian. Kiểm thử đơn vị - kiểm tra nói chung - là một công cụ bạn học cách sử dụng phù hợp để giúp bạn, không phải là việc vặt bạn phải thực hiện cho mọi thứ.

Có một loạt các bài đăng blog tuyệt vời về việc sử dụng TDD và thử nghiệm đơn vị cho nhà phát triển trò chơi tại đây: http://gamesfromwithin.com/stepping-ENC-the-looking-lass-test-driven-game-development-part-1

"Đơn vị" là đoạn mã có thể kiểm tra nhỏ nhất, thường là một hàm hoặc một lớp. Một bài kiểm tra đơn vị là một đoạn mã khác thực hiện đơn vị mã đó để đảm bảo nó hoạt động như dự định. Một đơn vị mã có thể có nhiều thử nghiệm, để bao gồm tất cả các trường hợp.

Thông thường, các thử nghiệm không được bao gồm trong bản dựng chính của dự án. Thay vào đó, có một cấu hình xây dựng riêng biệt để thử nghiệm bao gồm tất cả các mã kiểm tra và tạo ra một chương trình chạy tất cả các thử nghiệm và báo cáo kết quả. Một khung thử nghiệm sẽ cung cấp tất cả các giàn giáo cho việc này và được khuyến nghị, mặc dù không thực sự cần thiết. Nếu bạn hoàn toàn mới để thử nghiệm, ban đầu bạn có thể tốt hơn khi viết bài kiểm tra đặc biệt của riêng bạn, để đảm bảo bạn hiểu mọi thứ đang diễn ra.

Bao gồm nhiều mã nhất có thể bằng các thử nghiệm, ưu tiên mã mà bạn không tự tin hoặc mã dễ bị hỏng và có thể bị phá vỡ bởi các thay đổi trong tương lai. Bạn nên chạy thử nghiệm thường xuyên, lý tưởng sau mỗi thay đổi mã.