Kiểm thử đơn vị có khả thi trong lập trình trò chơi không?

Question

Tôi thích ý tưởng thử nghiệm đơn vị nhưng tôi gặp sự cố khi áp dụng nó cho lập trình trò chơi. Trò chơi có trạng thái cao và thường mã không tự chia thành các đơn vị riêng biệt. Theo kinh nghiệm của tôi, hầu hết các chức năng thay đổi trạng thái thay vì trả về các giá trị.

Hãy xem xét một hành động đơn giản như playerJump(height). Tôi rất muốn có một bộ kiểm tra kiểm tra nhiều trường hợp để đảm bảo rằng nhảy luôn hoạt động như mong đợi. Tuy nhiên, hàm này có thể sẽ không trả về giá trị nào và có tác dụng phụ là, player.velocity.y = -height và checkCollisions(player). Tôi không thể nghĩ ra một bài kiểm tra đơn vị rõ ràng để xây dựng xung quanh điều này.

Thử nghiệm đơn vị có thực sự không khả thi trong các ứng dụng có trạng thái cao như trò chơi không? Là những lợi thế của thử nghiệm đơn vị tuyệt vời như vậy mà nó sẽ có giá trị trò chơi lập trình chức năng?

---

Cập nhật:

Games từ bên trong có một loạt các bài báo trong chiều sâu về việc sử dụng Test Driven Development trong các trò chơi. Tôi rất khuyến khích họ cho bất kỳ ai quan tâm đến chủ đề này. Dưới đây là bài viết đầu tiên:

http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

Answer 1

Thường mã không phá vỡ bản thân thành các đơn vị khác nhau.

Đó chỉ là thiết kế kém. Mã không tự biến thành bất kỳ thứ gì. Bạn, nhà thiết kế, phải áp đặt một cấu trúc trên mã để bạn có thể chứng minh rằng nó thực sự hoạt động.

Tuy nhiên, chức năng này sẽ có khả năng quay trở lại không có giá trị ...

Thì sao?

... và có tác dụng phụ là, player.velocity.y = -height và checkCollisions(player).

Sau đó, kiểm tra điều đó.

Tôi không thể nghĩ ra một thử nghiệm đơn vị rõ ràng để xây dựng xung quanh điều này.

Tại sao không? Bạn vừa đưa ra một đặc điểm kỹ thuật tuyệt vời cho các kết quả của hàm.

Bạn có thể cần một vài đối tượng giả để thay thế Trình phát hoàn toàn bằng MockPlayer được đơn giản hóa dễ dàng hơn để kiểm tra.

Nhưng đặc điểm hoạt động của bạn là hoàn hảo. Chỉ cần kiểm tra những điều bạn mô tả.

Answer 2

Bài kiểm tra đơn vị có thể hữu ích cho nhiều thư viện cấp thấp mà bạn có thể sử dụng với mã trò chơi nhưng tôi nghiêm túc nghi ngờ rằng nó được sử dụng nhiều cho công cụ cấp cao hơn. Trò chơi thường là mô phỏng và dựa vào số lượng lớn trạng thái được chia sẻ mà không thể mô phỏng và thử nghiệm một cách có ý nghĩa một cách có ý nghĩa. Thường thì các chức năng trong trò chơi không trả về bất kỳ loại giá trị nào mà bạn có thể kiểm tra ngay lập tức mà thay vào đó hãy đặt một quá trình chuyển động cần hoàn thành tại một số điểm trong tương lai. Kiểm tra hành vi như vậy là đáng giá nhưng đòi hỏi một cách tiếp cận khác biệt đáng kể đối với ý tưởng thử nghiệm đơn vị thử nghiệm các đoạn mã trong sự cô lập.

Answer 3

Kiểm tra đơn vị không quan tâm đến cách đơn vị của bạn "trạng thái" như thế nào. Bạn có một đoạn mã độc lập hơn hoặc ít hơn, và nếu vector đầu vào và đầu ra của nó là rất lớn thì việc thử nghiệm là khó khăn. Các vector này có được đặt dưới dạng các trạng thái trước và sau khi thực thi không thay đổi một chút về thử nghiệm hay không. Tuy nhiên, nếu bạn muốn cho chúng tôi biết rằng bạn không thể nghĩ ra một cách thích hợp để xác định các trường hợp thử nghiệm như trong các bài hướng dẫn/bài kiểm tra đơn vị có đầu óc đơn giản, tức là đối tượng thử nghiệm là "f (x) = y", sau đó có, tôi đồng ý, bạn sẽ có một thời gian khó khăn chứng minh rằng vài (x [100], y [99]) vectơ mà một con người mía đến với sản lượng bảo hiểm đầy đủ (numerics!). Cố gắng xây dựng các thuộc tính tích hợp và bất biến và đi thử nghiệm tự động.

Answer 4

Hãy xem PEX để tạo thử nghiệm đơn vị tự động. Nó sẽ tạo ra các bài kiểm tra đơn vị cho tất cả các biến thể đầu vào có thể, sẽ giúp bạn kiểm tra nhiều kết hợp có thể.

Answer 5

Lập trình là lập trình. Bài kiểm tra đơn vị rất hữu ích cho bất kỳ loại ứng dụng nào vì chúng giúp bạn phát hiện và sửa lỗi (và thường quan trọng hơn, hồi quy vô tình được giới thiệu khi bạn mã refactor) ngay lập tức và hiệu quả. Có một số lĩnh vực hành vi cấp cao khó kiểm tra đơn vị, nhưng đó không thực sự là những bài kiểm tra đơn vị - chúng chủ yếu để kiểm tra các phương thức riêng lẻ hoặc các phần nhỏ của codebase thực hiện những gì chúng được cho là làm. Đối với các hành vi cấp cao hơn, bạn cần phải áp dụng các phương pháp thử nghiệm khác (kiểm tra hồi quy, ví dụ: cho ăn một chuỗi đầu vào cố định vào trò chơi và sau đó kiểm tra xem bạn có nhận được kết quả tương tự mọi lúc hay không. vị trí cố định trong suốt một cấp và kiểm tra xem chúng có tạo ra cùng một hình ảnh giống nhau (hoặc ít nhất là tương tự) không)

Ví dụ về PlayerJump của bạn là một trường hợp như vậy. Bạn có thể đơn vị hoặc hồi quy kiểm tra điều này bằng cách cô lập nó với đầu vào không đổi (lập trình đặt nhân vật người chơi tại một vị trí cố định trong một cảnh thử nghiệm đơn giản và kích hoạt sự kiện nhảy, sau đó kiểm tra xem va chạm của anh ta hoặc nơi an nghỉ cuối cùng là phù hợp. thư viện của các đối tượng khác nhau mà người chơi có thể nhảy "tại", bạn có thể bao gồm rất nhiều trường hợp kiểm tra (ví dụ: nhảy thành công trong khoảng cách của khoảng cách nhảy tối đa được quy định)

Ngoài ra, trò chơi yêu cầu Điều này sẽ tìm thấy những trường hợp kỳ lạ mà bạn đã không bao gồm với các bài kiểm tra tự động, nhưng quan trọng hơn nó sẽ trả lời một câu hỏi mà tự động kiểm tra sẽ không bao giờ trả lời: Liệu nó "cảm thấy" đúng Đây có phải là những bài kiểm tra chỉ một con người có thể thực hiện không.

Answer 6

Trải nghiệm của tôi với đơn vị và tự động kiểm tra trong quá trình phát triển Crysis 2 có sẵn tại đây: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html Hy vọng điều đó sẽ hữu ích.

Tóm tắt:

thử nghiệm tự động cải thiện sự ổn định phân phôi, tăng năng suất cho cả người sáng tạo nội dung và kỹ sư thử nghiệm tự động là một công cụ hiệu quả để cải thiện chất lượng mã và giảm nguy cơ của việc phải làm thêm giờ The Game nghiệp như tổng thể là phản động nói chung, thử nghiệm tự động đáp ứng một số đối số bất hợp lý chống lại Đừng gọi nó là thử nghiệm, gọi nó là cái gì khác, gần như bất cứ điều gì khác (Nhìn vào hành vi-Driven-Phát triển) Hãy linh hoạt, viết bài kiểm tra tốt là khó khăn và yêu cầu các kỹ năng không có sẵn trong ngành công nghiệp game

Answer 7

Nhiều người lập trình trò chơi sử dụng Entity-component-system architecture.Họ làm điều đó bởi vì nó làm cho nó dễ dàng hơn để sửa đổi hành vi đối tượng trò chơi. Nhưng khi nó xảy ra, nó cũng giúp đơn vị kiểm tra mã của bạn dễ dàng hơn.