![[Php vigo][talk] unit testing sucks ( and it's your fault )](https://image.slidesharecdn.com/phpvigotalkunittestingsucksanditsyourfault-160707100624/85/Php-vigo-talk-unit-testing-sucks-and-it-s-your-fault-2-320.jpg)
![[Php vigo][talk] unit testing sucks ( and it's your fault )](https://image.slidesharecdn.com/phpvigotalkunittestingsucksanditsyourfault-160707100624/85/Php-vigo-talk-unit-testing-sucks-and-it-s-your-fault-3-320.jpg)
[Php vigo][talk] unit testing sucks ( and it's your fault )
- 1. Unit Testing Sucks … and it is your our fault
- 5. Testing
- 6. Testing
- 7. Testing Testing don’t suck: tests that suck, suck.
- 8. We care about clean code
- 9. ... but we forgot something
- 10. Writing better tests Tips and tricks for writing better tests
- 11. Subtle Differences #1: Test code is different from other code
- 12. 4 rules of Simple Design Passes its tests Minimizes duplication Maximizes clarity Has no superfluous parts
- 13. Rules for tests? Trustworthy Express the intent Flexible
- 14. Tips and Tricks #2: Choose better test names
- 15. What are we testing here?
- 16. Choose good names I don’t want to read the whole test case to know what is trying to test. Please. Pretty please. Problems
- 17. What are we testing here?
- 18. Tips and Tricks #3: Avoid logic inside tests
- 19. Avoid logic inside tests
- 20. 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
- 21. Tips and Tricks #4: Highlight the important stuff
- 22. 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
- 23. Assertions Use the name of the test for explaining the feature that you are testing.
- 24. 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. Tips and Tricks #5: Builders to the rescue
- 29. Building same objects We depend on the stability of the constructor / setter methods. If they change, we are screwed. We are forced to pass all the parameters, even if they are not important for the test. Problems
- 32. Tips and Tricks #6: Building your own DSL
- 33. No semantic
- 34. Single level of abstraction Single Level of Abstraction Principle
- 35. Single level of abstraction
- 40. Tips and Tricks #7: Don’t hide the important stuff
- 41. Rules for tests Trustworthy Express the intent Flexible
- 42. Rules for tests Trustworthy Express the intent Flexible
- 43. Duplication
- 44. 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"
- 45. Typing isn’t the bottleneck "Programming is not about typing... it’s about thinking" - Rich Hickey
- 46. Usual suspects Set Up Data Providers
- 47. Techniques
- 48. Usual suspects Set Up Data Providers
- 49. 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
- 50. Data Providers
- 51. Explicit Set Up™
- 52. Usual suspects Set Up Data Providers
- 53. 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
- 54. Data Providers
- 55. Solutions Use Explicit Set Up ™ for the important stuff Don’t mix different test cases in one provider Avoid logic inside providers
- 56. Tips and Tricks #8: Mocking, the right way
- 57. Test Doubles
- 58. Test Doubles
- 59. Test Doubles Test doubles are objects that we create to help us test our system
- 63. Dummy
- 64. Dummy Use the real object unless its instantiation has side effects or is expensive somehow
- 68. Test Doubles Avoid test doubles for Value Objects
- 69. Test Doubles Avoid test doubles for Value Objects Think twice before using test doubles for Entities
- 71. Command Commands change the state of a system but do not return a value
- 72. Query Queries return a value and don’t change the observable state of the system Free of side effects
- 73. Test Doubles Use stubs to force a query to return a specific value so you guide the execution path of the test
- 74. 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
- 75. Without Test Doubles is this still unit testing?
- 76. Without Test Doubles What’s a unit?
- 79. Decoupling Don’t modify your tests when refactoring. It would couple the test to the current implementation
- 80. Tips and Tricks #9: How much testing is enough?
- 81. How much to test "Write tests until fear is transformed into boredom"
- 82. How much to test Confidence Communication Success!
- 83. How much to test Confidence & communication are the goals High Code coverage is not a goal: is a side effect
- 84. #10: Think. Don’t blindly follow rules (like these) Tips and Tricks
- 85. Everything is a trade-off
- 86. 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.