Black Box testers don't care about Unit Testing. Their main goal is to validate the application against the requirements without going into the implementation details.
But as a curiosity or Out of the box thinking, have you ever wondered how developers test their own code? What method do they use to test before releasing code for testing? How is dev-testing important in an agile process? The answer to all this is Unit Testing. I want to educate you on the importance of Unit Testing so that development and testing teams can work more collaboratively to design, test and release an excellent application.
Who knows in the future some of you may even switch to white box testing and use these code validation and improvement techniques!
What You Will Learn:
What Is Unit Testing?
Unit Testing is not a new concept. It's been there since the early days of 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 In SDLC
Importance Of Writing Unit Tests
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 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 a nightly build run unit test suite should run and report should be generated. If any of the unit tests have failed then the 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 don't write them at all. It's even more important to provide sufficient time and a supportive environment for real benefits.
- Testing can be done in the early phases of the software development lifecycle 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
- Fewer 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 tests 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.
Unit Testing Cycle
What Makes A Good Unit Test?
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
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
Misconceptions and Truths
- It takes more time to write code with Unit test cases, and we don't have time for that – In reality, Unit Testing would save your development time in the long run.
- Unit testing will find all bugs – It won't, as the intent of the Unit test is not to find bugs but develop robust software components that will have fewer defects in later stages of SDLC.
- 100% code coverage means 100% test coverage – This does not guarantee that code is error-free.
While Unit Testing offers many advantages, there are also limitations involved with using it. Rigorous discipline and consistency are required throughout the software development process to overcome limitations and get the intended benefits.
Your Comments are Most Welcomed!
As a black box tester, what are your observations about Unit Testing on your team? Does anyone have a better idea for successful Unit Testing?