Learn Test Driven Development in Java

12,358 views
11,956 views

Published on

This course provides everything you need to know to get started with test driven development in Java.

NEW! Discount codes for the online course!

If you like the look of these slides and would like to take the online course on Udemy, use discount code TDDSLIDES for a massive discount - https://www.udemy.com/learn-test-driven-development-in-java/?couponCode=TDDSLIDES

This course covers test driven development from scratch, through video lectures, demonstrations of practising a test driven approach, and through exercises for you to complete, allowing you to gain valuable experience in using TDD.

For the very best in interactive courses for software developers see http://www.uncademy.io

Published in: Technology
1 Comment
12 Likes
Statistics
Notes
No Downloads
Views
Total views
12,358
On SlideShare
0
From Embeds
0
Number of Embeds
46
Actions
Shares
0
Downloads
275
Comments
1
Likes
12
Embeds 0
No embeds

No notes for slide

Learn Test Driven Development in Java

  1. 1. Test Driven Development in JavaWednesday, 14 November 12
  2. 2. About me! Matthew Todd matthew.todd@fluentsoftware.co.uk @matthew_todd Working with developers, continuously improving agile practiceWednesday, 14 November 12
  3. 3. What is TDD?Wednesday, 14 November 12
  4. 4. Testing timeline 1994: Kent Beck creates SUnit test framework 1999: Extreme programming explained published 1989: First tests on punchcards 1995: TDD Demo 2000: JUnit.org launchedWednesday, 14 November 12
  5. 5. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tool s Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left moreWednesday, 14 November 12
  6. 6. Wednesday, 14 November 12
  7. 7. Test spectrum Full system test Automated integration/acceptance Testing in concert Component test Unit test Single function testWednesday, 14 November 12
  8. 8. 1. Write testWednesday, 14 November 12
  9. 9. 1. Write test 2. Test fails!Wednesday, 14 November 12
  10. 10. 1. Write test 2. Test fails! 3. Write codeWednesday, 14 November 12
  11. 11. 1. Write test 2. Test fails! 3. Write code 4. Test passes!Wednesday, 14 November 12
  12. 12. 1. Write test 2. Test fails! 3. Write code 4. Test passes! 5. RefactorWednesday, 14 November 12
  13. 13. 1. Write test 2. Test fails! 3. Write code 4. Test passes! 5. RefactorWednesday, 14 November 12
  14. 14. Why TDD?Wednesday, 14 November 12
  15. 15. Proactive VS Reactive Seek out problems early on Test late Validate requirements Only respond to defects Validate code Focused on debuggingWednesday, 14 November 12
  16. 16. Relative cost of change Cost Unit test Live system TimeWednesday, 14 November 12
  17. 17. Requirements Drive out requirements issues earlyWednesday, 14 November 12
  18. 18. Rapid feedback Many small changes VS One Big Change™Wednesday, 14 November 12
  19. 19. Collaboration Enables developers to work togetherWednesday, 14 November 12
  20. 20. Values refactoring Refactor often to lower impact and riskWednesday, 14 November 12
  21. 21. Design to test Testing driving good design practiceWednesday, 14 November 12
  22. 22. Tests as information Documenting decisions and assumptionsWednesday, 14 November 12
  23. 23. Sounds great! So show meWednesday, 14 November 12
  24. 24. So, let’s get startedWednesday, 14 November 12
  25. 25. Reverse polish calculator 34+Wednesday, 14 November 12
  26. 26. Calculator walkthroughWednesday, 14 November 12
  27. 27. Reverse polish calculator Developed using a test driven approachWednesday, 14 November 12
  28. 28. “sounds simple, but what about real applications?”Wednesday, 14 November 12
  29. 29. “sounds simple, but what about real applications?”Wednesday, 14 November 12
  30. 30. “sounds simple, but what about real applications?”Wednesday, 14 November 12
  31. 31. SOLIDWednesday, 14 November 12
  32. 32. Single responsibilityOLIDWednesday, 14 November 12
  33. 33. Wednesday, 14 November 12
  34. 34. Wednesday, 14 November 12
  35. 35. SOpen/ClosedLIDWednesday, 14 November 12
  36. 36. Wednesday, 14 November 12
  37. 37. Wednesday, 14 November 12
  38. 38. SOLiskov SubstitutionIDWednesday, 14 November 12
  39. 39. Wednesday, 14 November 12
  40. 40. SOLInterface segregationDWednesday, 14 November 12
  41. 41. Wednesday, 14 November 12
  42. 42. Wednesday, 14 November 12
  43. 43. SOLIDependency inversionWednesday, 14 November 12
  44. 44. Wednesday, 14 November 12
  45. 45. Wednesday, 14 November 12
  46. 46. Isolating dependencies Dependency Test target x Test double TestWednesday, 14 November 12
  47. 47. Test Doubles Stubs Fakes MocksWednesday, 14 November 12
  48. 48. Test Doubles Stubs Fakes MocksWednesday, 14 November 12
  49. 49. Stubs Providing state-based verificationWednesday, 14 November 12
  50. 50. Test Doubles Stubs Fakes MocksWednesday, 14 November 12
  51. 51. Fakes Providing simplified replacementsWednesday, 14 November 12
  52. 52. Test Doubles Stubs Fakes MocksWednesday, 14 November 12
  53. 53. Mocks Providing behaviour based verificationWednesday, 14 November 12
  54. 54. Stubs Assertions made Fakes directly in test method Mocks Assertions made by mock objectWednesday, 14 November 12
  55. 55. Test double demonstrationWednesday, 14 November 12
  56. 56. Mock frameworksWednesday, 14 November 12
  57. 57. Wednesday, 14 November 12
  58. 58. Wednesday, 14 November 12
  59. 59. app ropr iate ks w here amewor r mock fr Conside Test balanceWednesday, 14 November 12
  60. 60. Dealing with the legacyWednesday, 14 November 12
  61. 61. Code we cannot change Dealing with the legacy Someone else’s code? No interfaces?Wednesday, 14 November 12
  62. 62. So, now we can test it!Wednesday, 14 November 12
  63. 63. So, now we can test it! What makes a good test?Wednesday, 14 November 12
  64. 64. Test principlesWednesday, 14 November 12
  65. 65. FIRSTWednesday, 14 November 12
  66. 66. FastIRSTWednesday, 14 November 12
  67. 67. FIndependentRSTWednesday, 14 November 12
  68. 68. FIRepeatableSTWednesday, 14 November 12
  69. 69. FIRSelf-validatingTWednesday, 14 November 12
  70. 70. FIRSTimelyWednesday, 14 November 12
  71. 71. TDD Anti-patternsWednesday, 14 November 12
  72. 72. Anti-pattern: the singletonWednesday, 14 November 12
  73. 73. Anti-pattern: the singleton Who uses this singleton? Who owns this singleton? What behaviours does it provide?Wednesday, 14 November 12
  74. 74. Anti-pattern: create the world @Before public void initialiseTests() { loadBalancer = createMockLoadBalancingService(); server1 = createMockServer(); server2 = createMockServer(); loadBalancer.addServer(server1); loadBalancer.addServer(server2); dbEngine = new DBEngine(); dbEngine.addTable("users"); dbEngine.addTable("profiles"); dbEngine.addTable("posts"); userProfileService = new Mock<UserProfileServer>(); adminUser = new User("admin",true); user1 = new User("alice",false); user2 = new User("bob",false); userProfileService.register(user1); userProfileService.register(user2); user1.connectWith(user2); ... Wednesday, 14 November 12
  75. 75. Anti-pattern: create the world Test burden increases over time Test complexity increases Often a sign of application complexityWednesday, 14 November 12
  76. 76. Anti-pattern: completely mocked @Test public void testingNothing() { MockServiceFactory factory = new MockServiceFactory(); Mock<UserService> userService = new Mock<UserService>(); factory.add(userService); User user = new User("bob"); userService.add(user); assertEquals("bob",userService.getUsers()[0].name()); }Wednesday, 14 November 12
  77. 77. Test boundaries Class(es) under test Out of test scopeWednesday, 14 November 12
  78. 78. Anti-pattern: exceptional test @Test public void testUserCreation() { userService.createUser("bob"); }Wednesday, 14 November 12
  79. 79. Anti-pattern: exceptional test @Test public void testUserCreation() { userService.createUser("bob"); } Good coverage, but poor validationWednesday, 14 November 12
  80. 80. Anti-pattern: usually passes com.example.UncertainTest com.example.UncertainTest com.example.UncertainTest com.example.UncertainTest com.example.UncertainTestWednesday, 14 November 12
  81. 81. Anti-pattern: usually passes Control threading and access to resources We need to be able to trust our testsWednesday, 14 November 12
  82. 82. Anti-pattern: one big test @Test public void testEverything() { userService.createUser("alice"); assertEquals(1,userService.getUserCount()); userService.createUser("alice"); assertEquals(1,userService.getUserCount()); userService.createUser("bob"); assertEquals(2,userService.getUserCount()); userService.dropUser("alice"); assertEquals(1,userService.getUserCount()); User bob = userService.getUser("bob"); assertNotNull(bob); ...Wednesday, 14 November 12
  83. 83. Anti-pattern: one big test testUserCreation testEverything testCreatingDuplicateUser testDroppingUserWednesday, 14 November 12
  84. 84. Anti-pattern: the slow testWednesday, 14 November 12
  85. 85. Anti-pattern: the slow test Should be quick to pass Should be quick to fail Run frequentlyWednesday, 14 November 12
  86. 86. Anti-pattern: second-class test @Test public void whoKnowsWhatThisTests() { createTestObjects(); testUser.setName("alice"); setupTestDependencies(); User user2 = new User("user2"); setupUser(user2); testManager.add(testUser); ... test(user2); }Wednesday, 14 November 12
  87. 87. Applying TDDWednesday, 14 November 12
  88. 88. When not to use TDD!Wednesday, 14 November 12
  89. 89. Continuous delivery Integration testing BDD TDD Design Manual testing User storiesWednesday, 14 November 12
  90. 90. Practice practice practiceWednesday, 14 November 12
  91. 91. TDD KataWednesday, 14 November 12
  92. 92. TDD Kata roman numerals 1 - convert text from normal numerals -> Roman numerals 2 - convert in the other direction tooWednesday, 14 November 12
  93. 93. TDD Kata FizzBuzz printing numbers from 1 to 100 ..but multiples of 3 should print Fizz multiples of 5 should print Buzz multiples of 3 and 5 print FizzBuzz 1 2 Fizz 4 Buzz Fizz 7 ...Wednesday, 14 November 12
  94. 94. TDD Kata roman calculator calculator only accepting roman numerals as input and output I + III = IVWednesday, 14 November 12
  95. 95. TDD Kata tennis implement simple tennis game http://en.wikipedia.org/wiki/Tennis#ScoringWednesday, 14 November 12
  96. 96. Thank you!Wednesday, 14 November 12

×