UNIT TESTING COMMON MISTAKES

Without doubt, unit testing can significantly increase the quality of your project. Unit tests, by definition, examine each unit of your code separately. But when your application is run for real, all those units have to work together, and the whole is more complex and subtle than the sum of its independently-tested parts. But still some testers make the same common mistakes while opting for Unit testing.

images

The mistakes mentioned below don’t necessarily undermine the benefits of unit-testing but they do serve to make the process less than ideal.

  • Writing mammoth tests. People often write one test method for each method they test with all their assets contained within that test method. Well, this cannot be considered completely incorrect, this will slow down testing as most test suites stop at the first failed assert. Consider an example, if a test method has ten asserts and the first one fails, no conclusion can be immediately made regarding the remaining nine asserts. As a result, you should fix the first failure before the remaining nine can be tested. This is particularly annoying when tests are automated and run on a regular basis. Consider splitting your tests by requirement and including no more than the minimum asserts necessary inside a test method to test the associated requirement.

  • Not updating tests as per the trending requirements. It is very obvious to understand that technology advances rapidly, and that gives the testers no reason to carry forward the tests that were written months before. The tests should be run on a regular basis. Modifications in requirements and code lead to a drift between the tests and what they are testing. It is imperative to run tests on a frequent basis, ideally automatically, and to keep tests in line with requirements.

  • What are the test cases testing? Unit tests cannot exist in a vacuum. Mislabeled or unsubscribed tests only lead to confuse which requirements they are testing. Sometimes asserts are self-explanatory but more often they are not and require further output to describe failures. Consider naming your test methods to describe what they are testing.

  • Invaluable test output. Depending on the testing library you use, your tests may already be generating needless output. Adding more output will only result in confusing test results. Positive test results should never output data to the test log. Negative test results should make use of the output facilities within the testing framework for uniform formatting.

  • Do not mock out the database. This is not good as your unit test will not verify that the code actually works – you have a strong dependency on the database scheme. If your code is accessing the database directly make an integration test instead of a unit test.

  • No code review of tests. When not reviewing tests you do not share the knowledge of best practices, the risk of having a bug in your test is higher, and you need code reviews to raise the quality bar for unit tests in your team. Always do the code review face to face or with screen sharing. Writing comments is just not as effective and you will miss the conversation.

  • Individuality. Mixing unit and integration test is a bad practice. Unit test should be able to run in memory anywhere whereas integration tests are dependent on configuration or require dependencies that might not be in place where they run. Whether you separate them in projects or using tags is not important. The risk of sneaking in a dependency from an integration test to a unit test is not a risk if they are in separate projects.

  • Naming is important. The name of the test method should describe it all. If there is a need for additional comments the name of the test method is probably not good enough. Go for the best descriptive name of the test method.

  • Be illogical – avoid logic in unit tests. Having logic in unit tests makes them harder to read and maintain and it is more likely to have errors. Logic in your unit test is an indication that you are not writing unit tests. Only do a few assertions per test. If you have many assertions it will be hard to maintain and it is likely that you have a test suite rather than a test in the test method. In that case split the test method into several tests.

3 essential tips for writing great Unit Tests

  • Make each test independent to all the others

  • Don’t configure unit-test settings

  • Name your unit tests clearly and consistently