Professional software developers write automated tests. It is not because they make a lot of mistakes, it is because :

they care about the product they develop.

about the product they develop. they want to be sure that their product works .

. they want their product easily adapt changes .

. they don’t want to commit, push changes and pray. They want to know that their changes do not break anything.

Here is a poem which puts emphasis on the importance of writing automated tests for software projects :)

99 little bugs in the code

99 little bugs in the code

Fix one bug, compile it again

101 little bugs in the code



This series of posts is for Unity3D game developers who wants to write automated tests for their game projects.

Part I - Unit testing in Unity3D

Writing unit tests is hard because there is a deep synergy between testability and good design. Michael Feathers has an excellent talk about how testability leads us to good design.

As I write this post latest Unity3D version is 5.3.2. Before diving into testing you should import Unity Test Tools package (which is developed by Unity Technologies).

Unity uses NUnit Framework for unit tests. Engineers at Unity took NUnit and wrote a UI for running tests inside the Unity editor. You can open the Editor Test Runner through menu “Window -> Editor Test Runner”.

You should place your unit test files under the Editor folder. Editor Test Runner then finds the tests automatically and displays them in a tree structure (see picture above) where you can run tests and see test results.

NUnit uses custom atributes to identify tests. Here is a list of all custom attributes in the NUnit.Framework namespace.

Test attribute marks a method as a test. Only this attribute is mandatory for writing tests, because the test runner finds your tests by searching methods annotated by Test attribute.

Methods annotated with SetUp attribute are called once before each test case. If you have 5 methods annotated with [Test] attribute then SetUp method runs 5 times.

TearDown methods are called once after each test case. If SetUp method fails or throws an exception, TearDown method will not run.

These two are for one time setup and teardown.

Suppose that you have 3 test cases in a test fixture. Then the execution order of all the methods would be:

TestFixtureSetUp SetUp TestCase1 TearDown SetUp TestCase2 TearDown SetUp TestCase2 TearDown TestFixtureTearDown

Enough talk, time to see some code. There is a demo project called CodeBreaker. At the time of writing this post the project is not complete yet. I am planning to add more tests and functionality to the demo project as I write more posts about testing unity projects.

The demo project is a simple implementation of two-player code breaking game called Mastermind.

Below is a sample unit test class taken from the demo project that demonstrate the usage of NUnit Attributes.

This is the first post of series about testing in Unity3D projects. In the next post I am going to write about using mocks in unit tests.

Finally, while writing unit tests always keep in mind that a good unit test :