Unit Testing in Unity — WHAT TO TEST?

The most common question that arises while doing Test Driven Development(TDD) or writing unit test cases is that “What should I test and what should I not test”?

Before diving into that part, let’s first get familiar with these terms(if you are not):

A Unit Test is defined as a test that is focused on a “unit” of code. We should design a unit test to validate that a small, logical, snippet of code performs exactly as you expect it to in a specific scenario.

With TDD, you write tests before you write your business logic. It is a different approach to coding, but it also ensures you’ve written your code in a testable way.

To learn more about TDD and how to implement it in Unity, please refer to this blog.

In this article, I’ll share with you some guidelines which can be used while unit testing components that ensure you don’t spend forever writing tests but provide enough coverage to keep you out of trouble.

WHAT I SHOULD NOT TEST:

• Unity’s inbuilt functionalities like Animator Controllers, Colliders, Raycasts, Unity UI, etc. You should assume they work correctly because they should have their own tests.
• Other framework libraries/3rd party plugins. For example, If you are working on an AR project then you need not write tests for ARKit/ARCore/Vuforia libraries.
• Code that has non-deterministic results. For example, If you are working on Ragdoll Physics or a function which is responsible for generating a random number, then you should not waste your time in writing tests for those function because you can not expect a definite number to test.
  You can verify how many times your methods are called.
  You can also stub the functions that have non-deterministic results.
• Trivial code. Constructors or properties (if they just return variables).
• Methods that call another public method.
• Private methods directly.

WHAT TO TEST:

• Business logic.
• Things that have some conditional logic.
• Utility methods - Performing string manipulations, sorting and searching of collections of data, etc.
• Collections passed as a parameter not changed in the method.

SOME TIPS AND GOOD PRACTICES:

• Consistent test names for all the tests.
• Split a unit test in a template type structure. For example:
  //Given: User is on home page
  //When: User clicks on Bonus button
  //Then: Bonus score should add to the total score
• Identify the inputs and outputs of the methods.
• Don’t go beyond the boundaries of the inputs and outputs.
• Unit Test cases should be independent. In case of any enhancements or change in requirements, unit test cases should not be affected.
• Test the edge cases only for the commonly used complex code. You can add the edge cases for the less critical code as well if your favourite hobby is to write test cases.
• We can ignore complex multi-threading code. It is assumed to be better tested with integration tests.
• We can also write cases to ensure the performance of the code.
• Perform unit tests frequently.

CONCLUSION:

Before writing the unit tests for the code, you need to keep these things in mind:

• Only to test that piece of code which is concerned about the business logic.
• Only to test the code that is written by you, not by some other 3rd party plugin.
• Does this directly test the inputs and outputs of the component?

Happy testing!