Unit testing is part of the development process, where a developer will write some tests to check if the basic functionality of their code is correct or not.
Lets have a look at some very basic functions.
Here we have 2 methods;
- addition – Adds the 2 numbers passed to it
- getRandBetween1and10 – Gets a randomly generated number between 1 and 10 (note in C# the upper bound is never reached 1,11 is 1,10)
so lets write some unit tests for these – we want a test method with an expectation and a result. Firstly we can create a test project and then write some test methods
Testing Addition
simple enough – we set the 2 numbers and a variable showing the expectation. then call the actual function with these and evaluate if they are equal.
Testing Random Between 1 and 10
EASY… this post is a breeze. We just do the same – copy paste it;
Ahhhh.. what do we expect? its a random number between 1 and 10… we don’t know what it will be. Can we do anything here?
Mocking Frameworks
We can sort of do something. we can refactor the code and then use mock objects, this is where the execution of the code will happen as in the production code but we manipulate the answers the methods give us. While this example is trivial this is fundamental in testing systems where customers are charged or contacted.
Firstly we need to create an interface. Mocking requires an interface to work. Interfaces are super handy as they naturally decouple dependencies in code. An interface is effectively a contract saying – anything that use me will HAVE to have the methods dictated. It means that you don’t necessarily need to care how something works, but simply that it must exist if it uses the interface.
Lets change this method slightly.
Our calculations class now inherits from the interface IRandom. This interface has one condition a method names getRandBetween1and10 must exist and return an integer.
Now we are in a position where we can mock this interface. We can start to write unit testing code. The full unit test can be seen below.
Here we are mocking (making a fake version) of the IRandom interface. With this we can force the method call to return a particular value (in this case 7). Once we are able to do this we can run the test. We can also verify the method was called once and only once.
At this point we can run our tests and they both pass!
Conclusion
OK… I know what you’re thinking, is there much point in faking something to test it? Well.. yes and no. This is a really trivial example, you could argue quite fairly that the test written actually gives you nothing, well other than possibly a green tick and some coverage that might keep a clueless manager off your back!
But imagine other uses for this, imagine systems which actually send push notifications to customers, or charge credit cards. you want to test the code within these systems but you don’t actually want to be messaging or charging customers whenever you run tests. this is where the mocking framework really adds value. It seems sometimes you just gotta fake it to make it…