Đơn vị thử nghiệm Dự án trò chơi C # / XNA


13

Tôi đã bắt đầu phát triển trò chơi kể từ khi tôi bắt đầu lập trình, nhưng không bao giờ nghiêm túc. Tôi làm việc như một nhà phát triển ứng dụng kinh doanh, nhưng tôi đang làm việc trên một số trò chơi trong thời gian rảnh rỗi.

Trong thế giới kinh doanh (trên ngăn xếp web microsft) ASP.NET MVC đang trở nên thực sự phổ biến, vì dễ kiểm tra đơn vị cách giao diện hoạt động.

Tôi đang tự hỏi những mẫu thiết kế nào (MVC, MVP, MVVM, v.v.) người ta có thể sử dụng để viết một trò chơi trong đó tất cả logic của trò chơi có thể dễ dàng kiểm tra đơn vị. Điều này có thể hoặc khả thi? Tôi có lãng phí thời gian của mình không, tốt hơn là thực hiện các bản dựng đầy đủ và sau đó chạy thử nghiệm loại "tích hợp" thay vì kiểm tra đơn vị?

Mã mẫu sẽ là tuyệt vời, nhưng một bài viết cũng hữu ích.

(Tôi đã cố thêm thẻ kiểm tra đơn vị, nhưng không yêu cầu đại diện ...)

Câu trả lời:


17

Đây là một bài viết hay mà tôi thấy rằng mô tả một kiến ​​trúc để tách biệt chức năng để làm cho nó không chỉ dễ dàng sử dụng lại mà còn có khả năng dễ dàng hơn nhiều để kiểm tra đơn vị:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Một số trò chơi sẽ được hưởng lợi từ một mô hình giống như MVC. Các trò chơi cờ như cờ vua và các trò chơi bài xuất hiện trong tâm trí. Trong hầu hết các trường hợp, tuy nhiên, đây là quá mức cần thiết.

Cá nhân tôi thấy nó là đủ để chỉ kiểm tra đơn vị những thứ có bản chất thuật toán. Những điều bạn sẽ phụ thuộc vào "chỉ hoạt động" khi bạn viết mã trò chơi và có thể rất khó theo dõi các vấn đề trong đó, nếu chúng không. Những thứ như kiểm tra giao lộ hoặc mã mạng.

(Những điều lý tưởng sẽ được xây dựng trong khung bên thứ 3 để bạn không phải viết hoặc kiểm tra chúng!)

Một kỹ thuật tôi muốn sử dụng để thử nghiệm đơn vị những thứ liên quan đến trò chơi là cái mà tôi gọi là "thử nghiệm đơn vị trực quan". Khái niệm cơ bản là hiển thị dòng đơn giản của bit mã được đề cập (ví dụ: hàm giao nhau) và một số phép gán phím hoặc chuột cơ bản để thao tác các đầu vào. Không ai nói các bài kiểm tra đơn vị phải được tự động hóa - họ chỉ cần chia mọi thứ thành các đơn vị riêng lẻ và kiểm tra chúng.


Câu trả lời tốt. Tôi cũng muốn đăng chính xác bài viết đó. Các hệ thống thành phần Game Object là một cách tuyệt vời để phân tách logic và có thể kiểm tra từng đơn vị này. Tuy nhiên, điều mà không có bài kiểm tra đơn vị nào có thể làm là các tương tác phức tạp của nhiều đường logic logic trò chơi tương tác trong thời gian thực theo trình tự ngẫu nhiên. Điều đó sẽ giống như cố gắng để kiểm tra đơn vị dự báo thời tiết. :)
Tìm hiểuCocos2D

Vâng tôi cũng làm cho những người kiểm tra nhỏ cô lập các bit cụ thể của chức năng. Tôi chắc chắn rằng bất kỳ thay đổi nào tôi thực hiện đối với API, v.v. Tôi luôn đảm bảo những thay đổi này vẫn hoạt động. Dễ dàng hơn nhiều để sử dụng lại các chức năng trong dự án tiếp theo của bạn.
Iain

3
Vâng, câu trả lời tốt, và tôi thích liên kết. Và tôi đã đồng ý với mọi thứ cho đến dòng cuối cùng, "Không ai nói các bài kiểm tra đơn vị phải được tự động hóa". :) Phải , có thể không - nhưng tất cả mọi thứ tôi đã đọc ngụ ý (hoặc nói hoàn toàn) rằng các bài kiểm tra đơn vị nên được tự động hóa , đến mức bạn chỉ nhấn một nút duy nhất để chạy tất cả các bài kiểm tra của mình. Mặt khác, càng có nhiều công việc liên quan đến việc chạy các bài kiểm tra, bạn càng ít có khả năng chạy chúng thường xuyên. Cấp, nếu bạn đang nói về mã hiển thị , việc kiểm tra đơn vị có thể khó hơn nhiều, thậm chí có thể.
Cyclops

Gần bốn năm trôi qua, và tôi cảm thấy mình đã phát triển sự hiểu biết tốt hơn về lý do tại sao "kiểm tra đơn vị trực quan" hoạt động tốt như vậy: Kiểm tra đơn vị là một công cụ phát triển. Một đơn vị kiểm tra tự động điển hình có thể cho bạn biết rằng một cái gì đó được phá vỡ. Nhưng một bài kiểm tra đơn vị trực quan có thể cho phép bạn khám phá các thuật toán rất phức tạp và giúp bạn nhanh chóng xác định lý do tại sao một cái gì đó bị hỏng (đặc biệt là khi kết hợp với chỉnh sửa mã trực tiếp). Thông thường, một bài kiểm tra trực quan có thể xác định các vấn đề mà bạn thường phải dự đoán để kiểm tra bằng mã hoặc các vấn đề không có câu trả lời "đúng" (ví dụ: điều chỉnh).
Andrew Russell

Và ý tưởng rằng các bài kiểm tra đơn vị cần phải được chạy "thường là đủ" (như trong: luôn luôn, theo cách tự động) là không có thật. Mã không thay đổi rõ ràng là không cần phải kiểm tra lại. Và khi mã đang được sửa đổi, nhà phát triển thực hiện các sửa đổi sẽ được thực hiện trong khi sử dụng các thử nghiệm có sẵn phù hợp (trực quan, dựa trên mã hoặc cách khác). Rõ ràng có tồn tại mã với một hồ sơ rủi ro nhất định trong đó thử nghiệm tự động là một khoản đầu tư thời gian đáng giá. Nhưng những kịch bản như vậy đặc biệt hiếm trong phát triển trò chơi.
Andrew Russell
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.