Unit Testing
Download as PPTX, PDF1 like102 views
The document outlines best practices for unit testing and test-driven development (TDD), emphasizing the importance of writing tests for small, independent code units. It highlights naming conventions for test classes and methods, the necessity to cover positive and negative scenarios, and the avoidance of print statements in favor of assertions. Additionally, it advises against skipping tests, the separation of test code from production code, and the use of mocking for external dependencies.
Unit Testing
- 1. Dev Unit Test and TDD
- 2. What is “Unit Testing” Unit test is examining the smallest testable unit of your code. It is not about finding bugs, it might be but secondary to examining and is different then Manual/QA/Integration testing. Unit testing should be part of design process similar to TDD (Test Driven Development).
- 3. Objectives Fail first/fast Code coverage TDD
- 4. Name it clearly Test class Test class for service class should be named as service class name with suffix “Test” E.g. MemberServiceTest for MemberService Class Test case/method Test case should be named after test unit name with prefix “test” Choose meaningful names E.g. testFindMember() for findMember(Integer memberId) E.g. testFindMemberNotUniqueResult()
- 5. What to test Positive scenarios Negative scenarios Borderline cases
- 6. One code unit at a time One code unit can have one to many test cases Write test for method that have the fewest dependencies first, and work your way up Change proof, very rarely need to change exiting test case or very minimum change required.
- 7. Use “Assertions”, avoid “Print” statements No use of print statements, except development phase. Makes test case cluttered, difficult to read.
- 8. Avoid unnecessary assertions As unit testing is part of design, write your test case only to cover one (at max two, including otherwise condition) assertion.
- 9. Test case must be independent Never try to interlink test cases Test case should be independent of other test case so that change in one will not impact other.
- 10. Try to use Mock Wherever possible try to use Mock-API (Mockito) to mock underlying/external resources, persistence calls Avoid assumptions or having constants inputs for dynamic, it may or may not work Such test cases will prove useless
- 11. Externalize test data Maintain external resource like properties file to externalize test data. TestNG – Has feature to do it, Arch Team will decide on it.
- 12. Avoid unit test for Configuration/Master data It is obvious that configuration will not be going to change. Single test case will suffice.
- 13. Ensure that test code is separated from production code In your build script, ensure that test code is not deployed with actual source code. Its a wastage of resource. This is for Arch Team. We are working on with Maven in place.
- 14. Do not skip unit tests Do not use @Ignore or comment (//) to skip execution. If some test cases are not valid now then remove them from your source code. Having invalid/static test cases in source code will not help anyone.
- 15. Lets strive for TDD
- 16. Thank You Session to follow 1. Practical Junit 2. Use of Mockito 3. TestNG – More features over Junit
Editor's Notes
- #3: Writing fast, bug-free code is easy, if it’s a) not too complex and b) written once, then never touched again. Of course, if you’re working on anything other than a throw-away mobile game, this is never the case. So in order to keep your code as high quality and maintainable as possible, you need tests. Tests allow you to add new features, without breaking what’s already there. Tests help you to make changes in your architecture, without damaging behavior. Tests enable you to find newly introduced bugs early and with little additional effort.