Continuous integration with Unity. Client side tests – Part 1



Summary

Tests are an important part of the development, and sometimes, a forgotten part. Is tedious write, maintain and remember to launch the tests, and when we realise their utility or want to use them, maybe is too late.

The continuous integration proposes and allows automate some processes in order to find the failures as soon as possible.

In this post, we’ll see how to launch unit tests (called in Unity “Edit Mode Tests”) everytime we make a SourceTree commit. If we the tests are passed, the commit will continue, if not, the commit will aborts.



Software needed

The programs used in which we have checked the proper functioning are:

Bitbucket Cloud

  • Windows 8.1:

Sourcetree 1.9.13.7
Unity 5.5.1p2, Unity 2017.4.3f1, Unity 2018.2.0b4

  • macOS High Sierra 10.13.4:

Sourcetree 2.7.3
Unity 2017.4.3f1

Let’s do it

First of all, we have to create our unit tests if we don’t have any. In other Unity versions, the process may differ a little bit, but we take as reference the 2017.4.3f1 version.

We open “Window” -> “Test Runner” and press “Create EditMode Test”.

This creates a script in the “Editor” folder that we slightly modified in order to launch an error or not (only for tests purposes). The resultant code is:

With this ready and our bitbucket repository also ready, we create into the path “.git/hooks” the file named “pre-commit”. *
* Note 1: The “.git” folder is hidden so you have to make it visible through “hidden files” in Windows or, for example, with the Funter application in macOS.
** Note 2: The hook only will work in macOS if you enable its execution permissions with the “chmod +x filename” command.

And we begin to create our hook. The hook will be launched always before a commit.

First, we define the paths to the files and folders we are going to use in the execution and a help function that we will use in the future to know if we are in a Windows or not.

Then, we launch the tests and retrieve the execution return.

According to the returned value, we have the following cases:

  • 0 – All has gone well and tests have passed.
  • 1 – Execution error. This can happen, for example, if you have the project opened with Unity (later we’ll see how to fix that).
  • 2 – At least one of the tests have failed.
  • 3 – Execution error. Probably the project doesn’t compile or there are some errors in the paths.
  • >3 – Other errors.

As I’ve said before, if the execution returns 1, probably we have the project open with Unity and thus blocked with the “UnityLock” file. So we proceed to make a project copy * in the path defined in the variable “COPY_FOLDER” and we launch the tests again retrieving the value.
* Note 1: As we can notice, the project copy differs depending on the OS.

After that, we show the proper message according to the returned value.

We clean the auxiliary files and folders (if needed).

And for last, we end the execution returning the saved value.

In SourceTree exiting with a non-zero status aborts the entire commit.

So if at least one test has failed or some error happens, the commit will be aborted.

If this happens, we probably need to go to Unity because we have broken some code and/or we need to update some test (or others possible errors).

Leave a Reply

Your email address will not be published. Required fields are marked *