As software developers, we sometimes have to create software solutions that run some complex calculations where there is no room for error (an example is in fintech applications), at other times we have to create software solutions for clients and we need to have a way to ensure that the logic of our code is uncompromised. The above situation calls for unit testing.

Unit testing (simply put) are blocks of code that act as independent check and balance to ensure that if at any point a software engineer changes the logic of a code in a way that contravenes the first logic, the solution won't able to run. For example, if I write code to pay every customer of a bank 10% interest on their account balance at the end of the month, by creating unit testing, even if I forget that the code was built to pay 10% and change it to pay 11% interest, the code won't run.

Unit test also serves as an independent witness if a software engineer is accused of foul play, both the client and software engineer are supposed to have seen the unit test as such it is relied upon as the unbiased judge and it can come in handy when working with clients who are prone to forgetting instructions they gave out.

Unit tests are always built independently from the code they're testing. If for example I create a class called PayClients, to run unit test I would create a PayClientsTest class in order to test the PayClients class. The unit test class can be broken into three processes: Arrange, Act, Assert.

The Arrange part of the unit test is where you declare all the necessary values and inputs that will be used in the test.

The Act part of the unit test is where you input the logic of the Test class and The logic of the code you're creating a test for, if we use the example above, the Act part is where you input the logic of the PayClients class and the PayClientsTest class.

The Assert part is where you compare the results of the logic of both the test class and the normal class. Following the example above, the Assert part is where you compare the results of the PayClients and the PayClientsTest. If the result isn't the same, the test will fail and the solution won't run until they both have the same result.

In massive projects Unit testing can be a lifesaver. You're rest assured that even if you forget some key logic of your code you won't be able to deploy bad code online, your unit test will flag it. One can say that unit test are useful in flagging runtime errors which are harder to detect by the IDE or code editor. IDE and code editors can easily spot compile time errors. In case you're confused about what an IDE, Code editor, runtime error and Compile error are you should scan through my blog posts. I've written on these topics in the past.

In summary, every software engineer ought to know how to create unit test and should also commit to using unit test on projects as it can save a lot of future hassles even if you feel setting up unit test is stressful.