Unity Unit and Integration Testing

This post is in reaction of a Reddit post that I saw about Unity and testing. I was surprised to see the amount of people against writing unit tests in their Unity game. Some of them claim that these enterprise practices do not apply for game development, which I disagree.

But they do have a point in that unit and integrations are not the end of all means of testing. Unit and integrations test are supplements to manual testing.

 In this post I will talk about my personal experience with Unity and how I started to integrate testing practices to my current games.

 The first major game I worked on was my senior design project, The Knowledge We Seek. The game was a co-operative VR game between a tablet player and a person in the Oculus Rift. We were a team of five developers and six artists, which meant there was a lot going on in the project. We did not have any unit or integration tests, we only had manual tests. The way we broke down the tests was for each feature, such the player selecting an item, would have their own scene file. This seemed like a good idea at first, but as the game got bigger, the more scene files we had to manage. At one point, whenever there was a major change, we couldn’t keep up updating the scene files. There was too many scenes update. Somehow we managed and in the end, we made an unique game. The only issue we had were random disconnect between players.

 Learning from that experience, it was evident that having only manual tests was not sustainable. That’s when I started to research about Unity’s testing support. Unity had unit and integration tests in its asset store. Eventually the unit test came standard with installation, but the integration test still remained in the asset store.

 My current game utilizes this. Features that we used to create test scenes for are now encapsulated in a test file that Unity’s test runner can just run. The integration tests have their own scene, but they are automated. This gives us flexibility and instant feedback.

 There was an issue where I had to swap the character controller component with rigid body. After making that change, I ran the integration test and saw that the player’s collision test failed. I made the necessary change and everything was green. Because I know that all other tests passed and only this specific test failed, I know for sure that this was the only spot that needed to changed.

 Now this doesn’t catch everything. We still have a manual test scene but now they are more like sandboxes. There was a bug that involve aiming relative to screen instead of the player that was only manual testing caught.

 I do admit that having your code testable requires a little more work. There are definitely more interfaces in the codebase and Unity’s integration isn’t the best. The main argument I heard is writing unit tests is costly and doesn't have enough benefit. The more feature we introduce, the more tests we will have.

 The payoff comes when the tests fail. Let say there was a working feature and then someone decides to do a major refactor. When the tests are run, they check that the refactor didn’t have any adverse side effect. If a test do fail, it will tell the developer where the problem lies.

Since our game have tests, we now have a Jenkin server that run these tests every time we push and after they pass, there is a build. Another plus about writing tests is that it forces me to write code that are more abstract and less tightly coupled. This allows my player class to now have mock controllers that I can use to make an AI opponent if I wanted to.

 Anyway, that’s my thought on it. Let me know what you think.