1. Test Driven Development Introduction Issued date: 8/29/2007 Author: Nguyen Phuc Hai

2. Agenda Introduction Unit test overview Refactoring Test Driven Development approach Q&A

3. Trainer’s profile Over seven years experienced in software industry on both product development and out-sourcing. Hand-over various positions from developers, technical lead, project manager, technical architecture and program/product managers.

4. Trainer’s profile (cont.) Be experienced in managing small, medium and large projects/program – Took oversight more than 100 associates in one of the biggest account in company Be experienced on technical design, technical management in various sizes of projects from small to enterprise applications on both desktop and web environment

5. Trainer’s profile Be recognized as an Agile expert that has experienced in managing Agile process, applying Agile practices. Maintain the blog that share experienced in software development on both technical and management areas (http://www.haiphucnguyen.net/blog/)http://www.haiphucnguyen.net/blog/

6. Unit test key ideas

7. Unit test - FAQs Check the link for some common concerns of applying unit test and its benefits: http://www.haiphucnguyen.net/blog/?p=40 http://www.haiphucnguyen.net/blog/?p=40

8. Unit test best practices Keep test method as simple as possible: – DRY principle (Don’t repeat yourself) – Re-use test set up across test cases: put non- trivial test data in test set up method – Clean test code as productive code Evident data All non-trivial methods must be passed unit test with 100% coverage ratio.

9. Unit test best practices Unit test independent with: – Other unit tests, order of unit test running – Environment (operating system, hardware configuration, database …) Fix broken test as soon as possible (it should be immediately) After fixing defect, write unit test to prevent it re-occur

10. Unit test best practices All test cases must be passed at the end of working day. Test project code, not library code Minimal maintenance of test code If you can not write unit test for some functionality that means your code has problem! Refactor it immediately

11. How to make code becomes testable Using interface in communication among layers, modules. Dependency injection Dependency lookup Methods/Constructors has as less parameters as possible (4 is the best number)

12. How to make code becomes testable Class is not depended in many other classes -> it is hard to initiate instance of this class One method has only one purpose Be careful with singleton class or static methods! And the most important: refactoring your code if it is not testable (esp. legacy code)

13. Refactoring Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

14. Refactoring (cont.) Whenever you think you can make more benefits with your new code: – Increase the re-usability – Make the code becomes testable – Avoid the rigid, fragile issues – Better performance – …

15. Refactoring – best practices Keep small change running before proceed another change. Unit test should be written to make sure refactoring does not change system’s behaviors. To legacy system: write test first, refactoring and verify result

16. Test Driven Development TDD is a technique to improve the quality of both code and design. Developers will write the test first, then writing the code to make it pass the test. They can refactor code to avoid issues (duplication or non-optimize code …)

17. TDD benefits Promoting high code coverage for productive code. Improving quality of architecture and code Prevent defects cost is less than detect defects cost

18. TDD Cycle Prepare a list of test cases Follow the TDD Rhythm: – Pick a test to implement – Write a fail test – Quickly make test green – Refactor to eliminate duplication

19. TDD – Things always do Write test-first Maintain to-do list Writing new code only if there is failing automated test Run all test all the time not only single isolated test

20. TDD – Things always do Job is done whenever complete implementation and all test have green status

21. TDD – Things never do Write test for trivial methods (such as getters/setters) Commit code with failed test Big upfront design and code that makes test first do not cover all cases of writing code

22. TDD best practices Write the simple test first, then write code. After that write test code for more complexity functionality Run test immediately whenever complete writing code If spending much time for writing code, break the functionality into smaller ones and applying TDD for these pieces

23. TDD best practices Whenever test code or productive code smells, refactor it immediately After writing code, use coverage tool to make sure productive code is covered 100% by test method. If some piece of code is not covered, your implementation has problem! Use mock objects if needed

24. Tools support TDD Various tools help developers easier to do TDD: – IDE: Eclipse, MS Visual Studio Team System – Build tools: Ant, Maven, Nant – xUnit tools: Junit, TestNG, DBUnit, Nunit, … – Coverage tools: JCoverage, NCoverage

25. TDD examples A user story of login page: – Presentation Layer: Login.html, Login.java – Service Layer: LoginService.java – Data Access Layer: LoginDAO.java More complex user story: applying acegi for authentication – authorization process: – Re-factor LoginService.java – Run test again

26. TDD examples (cont.) Write the mock up html file: Login.html Write test class: LoginTest.java Write test method for case user login success: @Test Public void testLoginSuccess() { …. }

27. TDD examples (cont.) Implement login function that pass the test Void onSubmit() { if (username.equals(“VietNam”)) { setResponsePage(Helloworld.class); } else { form.error(“Login fail”); }

28. TDD examples (cont.) Run LoginTest again and verify result (it has green color) Return the Login.java and add feature verifying user base on database Void onSubmit() { if (userService.getUser(userName) != null) { … }

29. TDD examples (cont.) The enterprise application that maintains the suite of test cases and number of test cases is growing daily: – Automation unit test – Continuous Integration

30. TDD examples (cont.)

32. Q&A Any question of unit test, refactoring and TDD is welcome

33. Thank you I hope you enjoy with this course. Any further discussion, please contact me at – Email: haiphucnguyen@yahoo.comhaiphucnguyen@yahoo.com – My blog: http://www.haiphucnguyen.net/blog/http://www.haiphucnguyen.net/blog/