Unit testing is not a new concept. It’s been there since the early days of the programming. Usually, developers and sometimes white box testers.
write unit tests to improve code quality by verifying each and every unit of the code used to implement functional requirements (aka test drove development TDD or test-first development).
Most of us might know the classic definition of unit testing –
“Unit testing is the method of verifying the smallest piece of testable code against its purpose.” If the purpose or requirement failed then the unit test has failed.
In simple words, unit testing means – writing a piece of code (unit test) to verify the code (unit) written for implementing requirements.
Unit testing is used to design robust software components that help maintain code and eliminate the issues in code units. We all know the importance of finding and fixing the defects in the early stage of the software development cycle. Unit testing serves the same purpose.
Unit testing is an integral part of the agile software development process. When nightly build run unit test suite should run and report should be generated. If any of the unit tests have failed then QA team should not accept that build for verification.
If we set this as a standard process, many defects would be caught in the early development cycle, saving much testing time.
I know many developers hate to write unit tests. They either ignore or write bad unit test cases due to tight scheduled or lack of seriousness (yea they write empty unit tests, so 100% of them pass successfully ;-)). It’s important to write good unit tests or doesn’t write them at all. It’s even more important to provide sufficient time and supportive environment for real benefits.
- Testing can be done in the early phases of the software development life-cycle when other modules may not be available for integration
- Fixing an issue in unit testing can fix many other issues occurring in later development and testing stages
- Cost of fixing a defect found in unit testing is very less than the one found in the system or acceptance testing
- Code coverage can be measured
- Fever bugs in the system and acceptance testing
- Code completeness can be demonstrated using unit tests. This is more useful in the agile process. Testers don’t get the functional builds to test until integration is completed. Code completion cannot be justified by showing that you have written and checked in the code. But running unit test can demonstrate code completeness.
- Expect robust design and development as developers write test cases by understanding the specifications first.
- Easily identify who broke the build
- Saves development time: Code completion may take more time but due to decreased defect count overall development time can be saved.
Well, I’m not the right person to tell what makes a good unit test, but based on my observations on various projects I can definitely tell the characteristics of a good unit test. The bad unit test does not add value to the project. Instead, project cost increases significantly writing and managing bad unit tests.
How to write good unit tests?
- A unit test should be written to verify a single unit of code and not the integration.
- Small and isolated unit tests with clear naming would make it very easy to write and maintain.
- Changing another part of the software should not affect the unit test if those are isolated and written for a specific unit of code.
- It should run quickly
- A unit test should be reusable
Unit testing frameworks are mostly used to help write unit tests quickly and easily. Most of the programming languages do not support unit testing with the inbuilt compiler. Third party open source and commercial tools can be used to make unit testing even more fun.
List of popular unit testing tools for different programming languages:
- Java framework – JUnit
- PHP framework – PHPUnit
- C++ frameworks – UnitTest++ and Google C++
- .NET framework – NUnit
- Python framework – py.test