2008-07-Your-Unit-Tests-Should-Mind-Their-Own-Business

Unit Tests and 3 Components That Make Them Work

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.

  1. Trustworthiness

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.

  1. Maintainability

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.

  1. Readability

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.


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Images are for demo purposes only and are properties of their respective owners.
Old Paper by ThunderThemes.net © 2017

×