Chiến lược thử nghiệm cho các trò chơi

Tôi đã thừa hưởng một trò chơi giáo dục dựa trên web. Trong năm qua tôi đã làm việc để ổn định mã và thêm các tính năng mới. Hầu hết logic nằm ở front-end, vì vậy các bài kiểm tra đơn vị back-end, trong khi hữu ích, bao gồm một phần trăm nhỏ của mã.

Trò chơi đã đi đến điểm bắt đầu trở nên phức tạp. Có hai chế độ khác nhau cho mỗi trò chơi và trò chơi hoạt động khác nhau tùy thuộc vào chế độ. Ngoài ra còn có nhiều cờ khác nhau ảnh hưởng đến chơi trò chơi.

Tôi đã là một nhà phát triển ứng dụng hơn 10 năm nay và điều này làm tôi bối rối. Trong thế giới doanh nghiệp, một thuật toán luôn hoạt động theo cùng một cách. Tôi sẽ viết một bài kiểm tra đơn vị cho một thuật toán, tôi sẽ mong đợi giá trị 42 và nó sẽ bị lỗi nếu tôi không nhận được giá trị đó.

Khi nói đến trò chơi, tôi bị lạc. Làm thế nào để tôi kiểm tra chúng? Tôi có người kiểm tra có sẵn cho tôi. Tôi có thể dành thời gian viết bài kiểm tra đơn vị.

Người kiểm tra là ... không đáng tin cậy. Họ không phải là người giỏi nhất trong việc tìm ra các vấn đề và tôi đã không cho họ hướng đi tốt nhất. Thiếu một tấn thời gian cho mỗi chu kỳ phát hành kiểm tra mọi hoán vị và kết hợp của trò chơi, tôi nên sử dụng chúng như một tài nguyên như thế nào?

Các bài kiểm tra đơn vị có vẻ hạn chế. Vì hầu hết logic là javascript (và tôi được thừa hưởng mã spaghetti), tôi có thể sử dụng bộ giao diện người dùng như Cucumber hoặc selenium để đảm bảo các tính năng nhất định đang hoạt động.

Đó có phải là chiến lược tốt nhất? Làm thế nào để các công ty trò chơi thử nghiệm trò chơi?

Tôi đã đọc câu hỏi " Phát triển hướng thử nghiệm cho các trò chơi phức tạp " (trong số những người khác trên trang web), nhưng nó không giải quyết được những gì tôi đang tìm kiếm. Tôi đang yêu cầu các chiến lược, không phải là ví dụ cụ thể về cách kiểm tra.

Trong thế giới doanh nghiệp, một thuật toán luôn hoạt động theo cùng một cách. Tôi sẽ viết một bài kiểm tra đơn vị cho một thuật toán, tôi sẽ mong đợi giá trị 42 và nó sẽ bị lỗi nếu tôi không nhận được giá trị đó.

Điều này không khác lắm trong các trò chơi. Sự hiện diện của hai chế độ và nhiều cờ trong trò chơi mà bạn đang làm việc không thay đổi bất cứ điều gì: nếu bạn có một chế độ cụ thể với một bộ cờ cụ thể, bạn sẽ vẫn nhận được cùng một giá trị khi thử nghiệm một phần của mã nguồn.

Với quá nhiều chế độ và cờ, trò chơi có thể nhanh chóng trở nên rất khó kiểm tra, vì số lượng biến thể có thể có. Để giảm thiểu rủi ro gặp phải khó khăn này sớm, bạn nên:

• Mock / stub nghiêm trọng . Giữ các bộ phận thử nghiệm nhỏ, và chế nhạo mọi thứ họ dựa vào.

  Nếu họ dựa vào thời gian, giả định đối tượng thời gian để luôn đưa ra một kết quả cụ thể hoặc một tập hợp các kết quả cụ thể, độc lập với thời gian thực tế.

  Nếu họ dựa vào random(), chế giễu nó để cung cấp một hằng số mỗi lần.

• Tái cấu trúc . Nếu các bài kiểm tra bắt đầu quá phức tạp hoặc nếu bạn thấy rằng một lớp, để được kiểm tra, yêu cầu mười hai đối số sau khi bạn triển khai Dependency Injection, trong khi nó chỉ yêu cầu hai trước đó, bạn cần phải cấu trúc lại mã.

• Câu hỏi các quy tắc kinh doanh thực tế của ứng dụng. Tôi đã ngừng đếm số lượng dự án gần như không thể kiểm tra được vì số lượng biến thể khác nhau được yêu cầu bởi các yêu cầu chức năng không ai cần cũng không hiểu được ngay cả các bên liên quan.

  Khi một trang web thương mại điện tử nhỏ cần mười trang để giải thích các yêu cầu chức năng được sử dụng để xác định cách tính giá của lô hàng, người ta không nên bắt đầu bằng cách viết bài kiểm tra hoặc mã, nhưng thay vào đó, nên quay lại với các bên liên quan và làm việc với họ để sản xuất yêu cầu lành mạnh .

Cuối cùng, tự động hóa mọi bài kiểm tra . Người kiểm tra là cần thiết để khám phá các tình huống trong đó ứng dụng thất bại. Sử dụng người kiểm thử để thực thi, lặp đi lặp lại, hành động tương tự ở mỗi lần sửa đổi là phản tác dụng và thiếu tôn trọng người kiểm thử: kiểm tra hồi quy nên được thực hiện bằng máy chứ không phải người. Mọi người, mặt khác, tốt hơn nhiều trong việc tìm kiếm các lỗi có thể. "Điều gì sẽ xảy ra nếu tôi ..." là một trong những kỹ thuật họ có thể sử dụng ("Điều gì sẽ xảy ra nếu tôi nhập một vài megabyte dữ liệu nhị phân chứa vài \ x00 vào một trường hỏi tuổi của tôi và xem điều gì sẽ xảy ra?"), nhưng cách tiếp cận chính thức hơn có thể được sử dụng là tốt.