Unit Testing Sucks (... and it's our fault)

Tips and tricks to make unit testing more effective.

Transcript

1. Unit Testing Sucks … and it is your our fault
2. Who am I? fiunchinho jose@armesto.net
6. Testing “Testing sucks!” - Everybody
7. Testing
8. Testing
9. Testing Testing don’t suck: tests that suck, suck.
10. We care about clean code
11. ... but we forgot something
12. Writing better tests Tips and tricks for writing better tests
13. Subtle Differences #1: Test code is different from other code
14. 4 rules of Simple Design Passes its tests Minimizes duplication Maximizes clarity Has no superfluous parts
15. Rules for tests? Trustworthy Express the intent Flexible
16. Tips and Tricks #2: Choose better test names
17. Choose good names I don’t want to read the whole test case to know what is trying to test. Please. Pretty please. Problems
18. What are we testing here?
19. What are we testing here?
20. Tips and Tricks #3: Avoid logic inside tests
21. Avoid logic inside tests Conditionals: You don’t know which path the test will take Loops: you could be sharing state between tests If tests have logic, who test the tests? Problems
22. Avoid logic inside tests
23. Tips and Tricks #4: Highlight the important stuff
24. Be concise Too much information in your tests make them hard to read Think about what details could you leave out Assert messages help us highlight behaviour Problems
25. Assertions Use the name of the test for explaining the feature that you are testing.
26. Assertions Use the name of the test for explaining the feature that you are testing. Then use assert messages to clarify what's the example under test and why is that tested.
27. Highlight the important
28. Highlight the important
29. Tips and Tricks #5: Don’t hide the important stuff
30. Rules for tests Trustworthy Express the intent Flexible
31. Rules for tests Trustworthy Express the intent Flexible
32. Duplication
33. Expressing the intent "The refactoring technique ‘Extract Method’ is not about saving lines of code to make it shorter, but about make the code more readable"
34. Typing isn’t the bottleneck "Programming is not about typing... it’s about thinking" - Rich Hickey
35. Usual suspects Set Up Data Providers
36. Techniques
37. Usual suspects Set Up Data Providers
38. Problems with Set Up Move important code out of sight Now you have to remember that the code was there Since code in setUp is generic for all test cases, you lose context on why is that code there Problems
39. Data Providers
40. Explicit Set Up ™
41. Usual suspects Set Up Data Providers
42. Problems with Providers Tend to make tests more complex The most meaningful parts of the test (input & output) are now outside the test Usually end up more complex than you expected Problems
43. Data Providers
44. Solutions Use Explicit Set Up ™ for the important stuff Don’t mix different test cases in one provider Avoid logic inside providers
45. Tips and Tricks #6: Builders to the rescue
46. Building same objects
47. Building same objects We depend on the stability of the constructor / setter methods. If they change, we are screwed. We are force to pass all the parameters, even if they are not important for the test. Problems
48. Building same objects
49. Building same objects
50. Tips and Tricks #7: Building your own DSL
51. No semantic
52. Single level of abstraction Single Level of Abstraction Principle
53. Single level of abstraction
54. Creating your DSL
55. Creating your DSL
56. Creating your DSL
57. Creating your DSL
58. Tips and Tricks #8: Mocking, the right way
59. Test Doubles
60. Test Doubles
61. Test Doubles Test doubles are objects that we create to help us test our system
62. Test Doubles Dummy Fake Stub Spy Mock
63. Test Doubles Dummy Fake Stub Spy Mock
64. Test Doubles Dummy
65. Dummy
66. Dummy Use the real object unless its instantiation has side effects or is expensive somehow
67. Test Doubles Stub
68. Test Doubles Mock
69. Components Value object Entity Service
70. Test Doubles Avoid test doubles for Value Objects
71. Test Doubles Avoid test doubles for Value Objects Think twice before using test doubles for Entities
72. Command Query Separation Command Query
73. Command Commands change the state of a system but do not return a value
74. Query Queries return a value and don’t change the observable state of the system Free of side effects
75. Test Doubles Use stubs to force a query to return a specific value so you guide the execution path of the test
76. Test Doubles Use stubs to force a query to return a specific value so you guide the execution path of the test Use mocks to assert that a command to another object has been sent
77. Without Test Doubles is this still unit testing?
78. Unit Test Unit test
79. Isolated Test Isolated test
80. Decoupling Don’t modify your tests when refactoring. It would couple the test to the current implementation
81. Tips and Tricks #9: How much testing is enough?
82. How much to test "Write tests until fear is transformed into boredom"
83. How much to test Confidence Communication Success!
84. How much to test Confidence Communication Success!
85. How much to test Confidence & communication are the goals High Code coverage is not a goal: is a side effect
86. #10: Think. Don’t blindly follow rules (like these) Tips and Tricks
87. Everything is a trade-off
88. Conclusions Testing makes you go faster. Throw some love to your tests. If you find yourself going slower, identify why. TDD makes all of this much easier.
89. Jose Armesto @fiunchinho