Automated tests are very important in software development. Besides documenting the use-cases of the code, automated tests allows setting up continuous integration, continuous delivery, etc.

In todays agile software development environment, these concepts are very important because they speed up iterating dramatically. It also decrease the pressure of builds, deployments etc on development teams. Setting up the development environment suitable for continuous integration/delivery, developers are no longer afraid of new releases. Without using these approaches, every release might become a headache because of the potential bugs and required hotfixes.

After releasing a project, developers no longer have control on the application environment. End users are on their own using the app and getting the updates. Because many apps are released everyday, it’ s very important having a good first impression with releasing bug free applications or updates.

Automated tests comes into the place at that point. They can save much time in the testing process. Instead of running the scenarios to test the flow of code, automated tests allow developers testing the units of the codebase which is the first line of defence against potential bugs and defects.

Unity supports unit and integration tests natively. I’ ll try to explain how you can setup and use these automated tests while you’ re working on a project.

Unity Test Runner

Unity test runner is a built-in tool which allows developers running the written unit and integration tests. It has an intuitive ui which explains itself and its functionality more or less.

After opening the test runner window from the top menu in Unity (Window > General > Test Runner) you’ ll see the list of tests written as you can see in the image above. Besides being able to run a particular test, you might run all of them at once as well. (Believe me, seeing the ticks next to the tests makes me feel very relaxed 😀 but that generally does not happen)

Unit Tests(EditMode)

Test driven development is a common approach in the software industry. I won’ t cover its details in the blog post(might write another one if you demand tho :)). If you don’ t have any idea regarding the TTD you might look into this page. 

Unit tests are intended to test the units in a code. What i mean with units are the methods/functions. Testing the methods reduce the risk of bugs greatly because you’ re now sure methods work as intended with proper proper parameters. Only important thing here is you’ ll be sure only with the cases you cover with your unit tests. This, however, is a good start.

Other thing that need to be kept in mind is the maintenance of the unit tests. As soon as a change is being made in the methods, their tests might need to be updated. You can handle this problem with a good software architecture tho.

Unfortunately MonoBehaviours are not suitable for unit tests. The reason is they live in the scene and there’ s not a living scene in edit mode tests. Edit mode tests just run the test codes in a special play mode which does not a lifetime, thus, does not have support for frame based operations like coroutines, etc.

Also the assembly setup must be proper for unit tests. Unity requires the test classes to be in either an Editor folder or in a test assembly. If you choose using a test assembly then it won’ t have reference to the Assembly-CSharp. To be able to test the methods, etc. you, somehow, must have a reference to those classes in your test assembly and this requires seperating these classes in another assembly as well. After seperating them, you might add this assembly to your test assembly as a reference.

Integration Tests (PlayMode)

These tests allows you to run the tests which are frame/time dependent. These tests run in a living scene so you might test backend service integrations or methods that require a timeline.

One good example would be writing integration tests for the requests that are made to a backend service. This guarantees that your requests work properly. The parameters you sent are correct and the result is as expected. I strongly advise writing integration tests in case of having a backend service in your app/game. This will speed up the learning of the backend endpoints as well as save you from extensive work when a change or problem happens on the backend. Because you’ ll have an already passed integration tests in your client, the problems relevant with the backend will be very easy to spot.

I hope that post covers the basics of test automation in Unity and clears some points for you regarding automation. I might write some further posts regarding the tests and their details in Unity if you ask for it :))

Best,