SpringOne Platform 2016 Speaker: Matt Parker; Engineering Director, Pivotal. TDD, the savior of bad code, the promise of a better world. And yet… so many teams have tried TDD and failed. It’s a deceptively simple practice that actually requires a good deal of craftsmanship and skill to wield effectively. Through explanations and examples, we’ll examine a number of common problems teams face, including: Test Coupling Many folks our community promote the idea that unit testing means having a test file for every production class, and a test for every public method. And yet this tightly couples tests to the underlying design patterns of the codebase, and makes it hard to refactor. We’ll look at a way to minimize the surface area of your testing and intentionally define an interface between your tests and production code. Mocking (Hammer of the Gods) Mockito (and libraries like it) have created very simple and powerful ways for Java developers to create and use test doubles in their tests. And yet those libraries have also led to a good deal of misunderstanding and misuse of test doubles. We’ll examine the five types of test doubles, their roles, and when they’re applicable – and we’ll also look at the common problems developers run into misusing these tools and concepts. Death by a Thousand Flakes Outside-in behavior driven development is a commonly used practice. And yet we have too often conflated “outside” with ”GUI” – with disastrous results. We’ll look at the problems this has caused, including slow test suites, flaky test suites, upside down testing pyramids, and more. Test Suite Bankruptcy When all of these bad practices combine, they lead to one place: test suite bankruptcy. We’ll examine a case study of a team that, with the best intentions, applied all of these practices together for the better part of a year, and was forced to declare test suite bankruptcy at the end. We’ll talk about the tell-tale signs that you are approaching bankruptcy, and what you should do if you ever find yourself in that situation (or inheriting that situation from others).

2. Matt Parker
@moonmaster9000

3. TDD
(the bad parts)

4. BUT FIRST
A CAUTIONARY TALE

17. WHY TDD?

18. GO FAST FOREVER

19. GO FAST FOREVER
CLEAN CODE

20. GO FAST FOREVER
CLEAN CODE
REFACTORING

21. GO FAST FOREVER
CLEAN CODE
REFACTORING
CONFIDENCE

22. GO FAST FOREVER
CLEAN CODE
REFACTORING
CONFIDENCE
TESTS

23. GO FAST FOREVER
CLEAN CODE
REFACTORING
CONFIDENCE
TESTS TDD

24. PROBLEM #1:
OUTSIDE-IN BDD

26. 1.Write acceptance test
2.Write controller test
3.Write model tests

27. SLOW

28. BRITTLE

29. COUPLED

30. FLAKY

33. OUTSIDE?

34. “Start at the outside
of what you want to
discover” - Joseph
Wilk

35. OUTSIDE != GUI

36. PROBLEM #2:
MOCKING

37. @RequestMapping(value = "/translate", method = REQUEST.POST)
@ResponseBody
public String show(Model model, @RequestParam String word){
return translationService.translate(word);
}

38. public void post_populatesModel() throws Exception {
TranslationService service = mock(TranslationService.class);
when(service.translate("apple")).thenReturn("appleway");
TranslatorController controller = new TranslatorController(service);
MockMvc mockMvc = standaloneSetup(controller).build();
mockMvc.perform(post("/translate").param("word", "apple"))
.andExpect(model().attribute("translation", "appleway"));}
}

39. DUMMY
STUB
SPY
MOCK
-----------------------
FAKE

40. THE LITTLE MOCKER
blog.8thlight.com/uncle-bob/2014/05/14/TheLittleMocker.html

41. S.O.L.I.D.
● cleancoders.com
● Agile Software Development:
Principles, Patterns, and Practices
● Pivotal Labs

42. HEXAGONAL TDD
moonmaster9000.github.io/hexagonal_tdd_in_ruby

43. PROBLEM #3:
UNIT TESTING

44. THREE LAWS OF
ROBOTICS TDD

45. 1. You are not allowed to
write any production code
unless it is to make a
failing unit test pass.

46. 2. You are not allowed to
write any more of a unit
test than is sufficient to
fail.

47. 3. You are not allowed to
write any more production
code than is sufficient to
pass the one failing unit
test.

48. “Every class should be
paired with a well-
designed unit test”

49. “Every public method
of every class should
be paired with a well-
designed unit test”

50. class ClassOneTest {
@Test
public void publicMethodOne {
//...
}
@Test
public void publicMethodTwo {
//...
}

51. ClassOne.java
ClassOneTest.java
ClassTwo.java
ClassTwoTest.java

52. <REFACTORING>

53. DESIGN PATTERN!

54. class ClassOneTest {
@Test
public void publicMethodOne {
//MOVED SOME TESTS
}
//...

55. class ClassThreeTest {
@Test
public void publicMethodOne {
//TESTS MOVED FROM ClassOneTest
}
//...

56. ClassOne.java
ClassOneTest.java
ClassTwo.java
ClassTwoTest.java
ClassThree.java
ClassThreeTest.java

57. TEST COUPLING

58. DESIGN PATTERNS

59. GO FAST FOREVER
CLEAN CODE
REFACTORING
CONFIDENCE
TESTS TDD

60. GO FAST FOREVER
CLEAN CODE
REFACTORING
CONFIDENCE
TESTS TDD

61. GO FAST FOREVER
CLEAN CODE
REFACTORING
CONFIDENCE
TESTS TDD

62. “Every class should be
paired with a well-
designed unit test”

63. “Every class should be
paired with a well-
designed unit test”

64. “Every behavior should
be paired with a well-
designed unit test”

65. MINIMIZE SURFACE
AREA

66. So….

68. THANK YOU

69. QUESTIONS?