At moments like these you will sit there sitting how on earth could you have affected his code
Every time you would make a small change to the code, you can re-run all the tests and verify that the application is working correctly. If you break something you know that only the few lines of code that you have written right now are the culprit and thus it is very easy to fix the problem.
To achieve this point you need to learn few other things such as mocking and some design principles that help you write loosely coupled code and to put the icing on the cake you need to learn how to write clean code so that you spend more time developing new features rather than grasping old code that was written by you or someone else in the past, but don’t worry I have got it all those things covered in this blog right 😉
Characteristics of a good Unit Test
A good unit test normally has some characteristics that make it stand out. Typically a unit should meet the following conditions:
- A unit test should always be fully Automated
- A unit test should never be needed to run in a specific order. You should be able to run it anytime and in any order and it should be conclusive.
- Should be decisive and not give different results at different time or in different conditions
- Unit tests should run in memory. That means that tests need to interact with database should be run separately (Those are integration tests).
- Unit test should be very fast. Imagine running thousands of tests every minute and each of them takes 2 seconds to run. Well you can say good bye to unit testing right there. J
- Unit tests should be readable. If you have to spend a lot of time understanding what a unit test is doing then they lose their benefit.
- Unit tests need to be maintainable. You need to understand that unit tests are not third class citizen. They are as vital as your real productions code and if you will have hard time maintaining them then chances are that you will stop using them which will ruin the initial intention of testing your entire application using unit tests.
- Your unit tests need to be trustworthy, which means that if the pass you know your code works. They should act as a flag to whether you commit your code to production or not? As a developer you need to have faith in unit tests just like your religion.
What is Test Driven Development
Now that we understand what does unit testing mean we can establish what Test Driven Development (TDD) is? TDD as the name implies is simply a technique of software development in which you let unit test drive your code. In short in TDD:
- You write a unit test that fails
- Then you write only the amount of code that is needed to make that unit test pass
- Once you make the test pass you refactor your code and make it more readable and maintainable
These three steps are also known as the Red, Green Refactor steps. This sounds ridiculously simple right? Well in actuality it is, but the amount of benefit that you can gain from writing code strictly in this manner is huge.
What benefits can we achieve from TDD?
With TDD you get all the benefits of Unit Testing plus some additional benefits. Because you are following three very small steps your focus is enormous and your productivity increases.
You only write the amount of code that needs to be written in order to make the test pass thus you are always following the YAGNI (You aren’t gonna need it) Principal. I have seen a lot of developers who will just be working on a class and will just write a lot of methods in it thinking they will come of use in the future. A classic example of this can normally be seen in classes for data access and I have seen developers just writing methods for Insert, Update, Delete etc even though they do not need them at that time, thinking that they will come of use later.
Because you are refactoring your code at the end of every iteration; you end up with a very fresh and well maintained code base. This alone has a huge impact on your code and makes you write code that is very easy to maintain and much more readable.
We have established the fact that in order to write code with complete confidence and authority, we have to adopt Unit Testing and eventually Test Driven Development. In modern age I see no other way of developing complex, enterprise level software. It takes time and some practice to adapt to these new concepts but trust me once you start adopting them, they will become your Oxygen! In the coming articles I will try to explain the types of unit tests and when to use them and also why we need mocking.