13
\$\begingroup\$

I am new into this field of testing. I just developed a basic game using unity engine but i want to test it.

I have checked with selenium but i don't know how to get the value that is being returned which has the information of the action that is being performed in the game. If i am able to get the value then i will be able to take necessary action accordingly.

\$\endgroup\$
3
  • 4
    \$\begingroup\$ This is a quite interesting question. I personally think that unit testing is quite underappreciated in game development. However, it sounds like you are more interested in automated integration testing, which is often really difficult to implement in game development. Especially when the game is using randomness. \$\endgroup\$
    – Philipp
    Commented Jun 15, 2016 at 11:25
  • \$\begingroup\$ Props for taking testing seriously & looking into tools for that job. You might want to ask on SO instead - they have a lot of Q&A on selenium. As @Philipp mentioned, some types of gaming testing are plain difficult to automate; i.e. I've yet to see an unattended test for checking visual effects. \$\endgroup\$
    – Pikalek
    Commented Jun 15, 2016 at 13:01
  • 1
    \$\begingroup\$ It's not clear what you want to test, but it seems that you're looking for a value which may be tested independently of the game - a value returned by a function. And if so, you could unit test this function and won't matter whether it is being used in the game or not. If it's not clear for you how to do it, let us know and I will try to write an answer involving unit testing. \$\endgroup\$
    – MVCDS
    Commented Jun 15, 2016 at 18:08

1 Answer 1

1
\$\begingroup\$

There are multiple ways to test a game, two most used are: unit and integration testing.

For unit testing you're testing the inner workings of the game, without actually running it. You can do this for specific modules which have dependencies abstracted away (e.g., logic that computes the Quest XP you get, based on a given set of factors; whether a given sound is played). Depending on how much you abstract your logic, you could test more, but for unity specifically, it might be harder given the way the game architecture is done (e.g., inheriting from monobehaviour). Nevertheless, applying OOP patterns like composition, you can extract bits of logic that can be tested in a deterministic way (e.g., physics), even if sometimes it can be seen as a bit extreme. It all depends on how much time you have, whether you started from scratch with the project or not, how much experience you have, etc. In general, I haven't seen much unit testing in games compared to the other non-game software projects. This kind of testing is quite easy to automate as you provide mocked behaviors that you simulate.

For integration testing, you interact with the "whole" game at a given time, when all parts are running. Depending on the depth of things you want to test, I see it might be very easy to outright impossible.

One idea would be to have an "integration test" build, which logs every (most) actions it does (i.e., spawning monster, playing sound, starting effect, spawning particle). After it runs for a given time, you can check the logs to see whether it matches a given pattern (this also depends on how random the game is, based on the inputs). Now, this sounds simple, but the question is: how you tell the game to do the wanted actions? Which brings me to the second idea.

Other idea would be to have kind-of server in the game, again, for testing purposes, which is able to process requests (e.g., via a REST API), and which acts upon the entities. The requests could be things like: move left, jump, rotate X degrees, change viewport, etc. With this approach you can also do the "checks" that the game is acting as expected, either by checking state directly, or verifying a virtual log of events that happened. This approach is used by other UI-testing tools for mobiles (e.g., Xamarin Test Cloud)

For the controlling part, if your game is touch/browser based, you can instead simulate the actions via a virtual touch/input device, but this is a bit more hard, depending on the actions complexity.

Another idea, with regards the visual aspect, is to take some reference screenshots, images during an initial phase, and comparing them after the same action sequence happened on a newer build. The comparison can have a specific deviation allowance, to guard against minor changes. During the tests, you can log the screens that didn't match and see the difference. It may be the case that the reference screens need to be updated due to different changes. In that case the game could be run again with the preset actions, and reference images be updated. This will probably not work very well with particle systems, or randomly-generated scenes, unless you use the previous idea to set some sort of seed, that is used to generate the particles.

For the sounds, it might be a bit harder, cause it will involve "listening" to the OUT device (which is not always possible IIRC, since it depends on the hardware of the system). But if it's possible you can do the same reference-based comparison as you do with the images.

I hope this sheds some light on how you could automatise the game testing.

Later Edit: I just see that there was another related question which might give you some pointers on how you'd do certain bits: Automated testing of games

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .