Unit Tests: Uncovering
Unit testing is one of the methods used in software quality assurance testing. Unit tests are called so because they test only a unit which is the smallest part in your system you can test. A unit can be a method or class, for example.
If we think of a simple representative scenario of unit test usage, let’s consider the “log in” service and the following situation: correct username but wrong password. The next thing to consider is expected behavior. Under given circumstances the system should return the “Wrong password” message. And this is what our unit test is called to validate. The main point here is that we test the system in isolation from any other concerns. In this case, we focus only on our “log in” service’s response.
3 Pillars of Unit Test Operation
OK, the basics are understood. Then, how do we get them going? Here are the 3 essential things that make unit tests helpful.
Unit tests are our parachute, so we need to trust them, because otherwise they are just useless. When your tests pass, how confident are you it means something? How do you know if it’s not always green or it just doesn’t test what expected? A common issue appears when you change or just refactor something, then run the tests, all are passing and you are still not sure if anything didn’t break. But if follow red, green and refactor cycle, then you may be sure. If all the tests are green, the module is fine and you don’t need to check that in another way.
Obviously, tests need care in the way production code does. When you modify production code, some your tests will break. This is a big issue since more tests need more attention.
First, we can reduce time spent on nurturing via writing a test against only public method, that is, contracts. If you specify some contract, you will likely not modify it as frequently as private methods. When you feel you need to test a private method, that’s a bad design sign and probably this method’s functionality belongs elsewhere.
Another thing to do is remove duplication in the tests and move parts which can vary in one place. You may use the factory method or the common test “set up”. In case some tests of the class need a different “set up”, split them in two test classes. Refactor your tests as often as the production code.
Since a unit tests is an executable specifications, you have to be able to understand and read them as such specifications. The most significant aspect in achieving readability proves to be good naming convention.
Use the given tips to create and perform better unit tests and ensure the success of your software QA testing process.