Unit testing is intended to validate that a class and its methods do what the developer intended them to do. Unit tests are not intended to replace functional or acceptance testing; rather, they ensure that the code we release to functional testing is better than it would be without our unit tests. With that in mind, at first what matters is that you start to write the unit tests first.
Never forget the formula: Write tests first.
JUnit test cases of existing application have got several issues. They will be addressed in this section. The following are the list of issues.
- Test case coverage is not enough for functionality.
- Like invalid/insufficient input data.
- Not all flows in a method were tested.
- Code coverage for test case is too low (side effect of the above problem).
- No boundary test cases.
- Most of them are Happy Path test cases.
- Some of the classes don’t have test cases. But there is no justification for not to have them.
To make system more stable, we HAVE to implement the following.
- Testing trivial code: Unit tests should test those segments of code that are likely to have defects when first developed, or are likely to have defects introduced when changed. Like all software development activities, there is a cost benefit analysis that can be applied to writing unit tests. It is not worthwhile to test trivial code. It is unlikely for simple getter/setter methods to change in the future.
- Validation tests: The Validation asserts the correct behaviour for data that isn’t valid (or is out of the domain). For example, passing null or empty references of an accommodation object to the method is a validity test. Method should gracefully log the error and return the control.
- Boundary Test cases: The boundary is a variant of a happy path test, but it asserts that the implementation works correctly at the boundaries of the domain. This is to avoid issues like indexOutofboundexceptions etc. For example, pass empty list to TestHelper.getPrioritisedSkus(). This method should not throw runtime exception.
- Avoid slowly executing test cases: Slowly executing test cases will discourage developers from executing test cases. Since in JUnit the setup and teardown are performed before and after each test method, this leads to unnecessary object population every time. Use effective means of caching of this data to avoid any further delay. This type of implementation will help in speeding up of execution of Flight search or TPP calculation test cases.
TechnoStixs.com is a dedicated weblog for Java/J2EE and web developers. We take pride in our work. Every publication is carefully analyzed, written and tested to ease the understanding of the topic or subject.
We cover Java Core Technologies, eCommerce, J2EE Frameworks, Web Service, Build Tools, Unit Test Frameworks and Others.
1,028 total views, 2 views today