Grumpy Testing Patterns

Slides from my "Grumpy Testing Patterns" talk that I gave at PHP Australia Conference on April 15, 2016

Transcript

1. Grumpy Testing Patterns Chris Hartjes PHP Australia Conference April 15, 2016
4. Personal Opinions Ahead
5. This isn’t about shaming people
6. Testing has been around almost as long as computer science itself
7. It pre-dates the rise of the internet
9. It’s never too late to care about automated tests for your application
10. So you’ve decided to write tests ❖ Is your code ready to test? ❖ Do you understand the testing tools? ❖ Do you understand some common testing patterns?
12. What Do I Like To See? ❖ Dependency injection in use ❖ Small objects with few methods ❖ Bootstrapping that allows for easy overriding
15. Don’t Lose Control ❖ Dependencies you cannot control means tests you cannot write ❖ Untested code can lead to weird bugs and unanticipated behaviour
16. How To Control Dependencies ❖ Think of your program flow as “message passing” ❖ Refactor code to create required dependencies outside of where they are used ❖ No shame in incremental refactoring towards testability
17. Dependency Management As “Message Passing” ❖ Architect your application so results and dependencies flow through it ❖ Keep “side effects” to a minimum ❖ Give opportunities for tests to create doubles of dependencies that need to be in specific states
20. Taming Side Effects ❖ in-memory databases using SQLite ❖ in-memory file systems using vfsStream ❖ “dependency overloading” using Mockery
21. In-Memory Databases ❖ Eliminates the side effect of modifying common databases ❖ Much better control over initial data sets
23. In-Memory Filesystems ❖ great for tests that need to read and/or write files ❖ no need to write code to clean up data after testing
28. Small objects with few methods
30. “Using Test-Driven Development tends to result in large numbers of objects with small numbers of methods. Single responsibility principle in action!”
31. “Again, your tests suck because your code sucks. No. Really.”
32. How To Detect Smelly Code ❖ Your tests require extensive setup steps ❖ Your code to set dependencies fills your editor screen ❖ It’s extremely difficult to tell if you’re getting the expected results
33. Extensive Setup Steps ❖ Does your app have complicated bootstrapping? ❖ Does it rely on hard-coded values for configuration options? ❖ How hard is it to swap out dependencies?
37. For those counting along: 24 lines of setup 5 lines of tests
39. For those counting along: 24 lines of setup 5 lines of tests for 7 lines of code
40. Not all smelly code is wrong
41. Other things I see people doing
45. “DO YOU NOT NOTICE HOW SIMILAR ALL THESE TESTS ARE?!?.”
47. “Just like duplicated code can be bad, duplicated tests can be bad.”
48. What else do I see that I don’t like?
49. Avoid These ❖ conditional statements in your tests! ❖ loops in your tests! ❖ creating a test double of the thing you are testing just so “the damn thing works”
50. “I’m sure I missed your favourite underused technique that is actually just lazy.”
51. Not all smelly tests are wrong
52. They represent things to keep an eye on going forward
53. Do You Understand The Tools? ❖ Do you know how to use the testing framework ❖ Do you know how test doubles work?
54. “The tools are hard to use”
55. The problem isn’t the tools
56. The problem is unrealistic expectations
57. Tests are code you write to prove your other code is right
58. Grumpy’s 4 Steps To Test Mastery
59. Step The First: Figure out your dependencies
60. Step The Second: Figure out your expected outcome
61. Step The Third: Write the test like everything already works
62. Step The Last: Write code until the test passes
63. Want to learn more? Search Github
64. Really. Best place ever to find tests.
65. https://github.com/opencfp/opencfp
66. “There are too many examples of well-written tests and clear instructions for people to claim ignorance of how to write tests or use the tools to execute them.”
68. Handling The Weird Stuff
69. Understanding Test Doubles
70. (people call them mocks)
71. Test Doubles “Use them when you have a dependency that is not under your control that needs to be in a specific state.”
72. Creating doubles ONLY WHEN REQUIRED is a good practice
73. So What Should We Double? ❖ database connections ❖ code that calls 3rd party API’s ❖ code that has side effects
74. Database Connections? ❖ does your unit test REALLY need to make sure the database is working ❖ lets you control the expected responses in terms of result sets or record ID’s
75. 3rd Party API’s? ❖ API use could be restricted (rate-limited, sandboxed for tests, pay-per-use) ❖ Again, are we in the business of testing their API or testing our code?
76. “As an aside, consider the use of contract-style tests as part of your integration test suite”
77. Weird Stuff To Test ❖ dependencies that you cannot inject without risky refactoring ❖ getters and setters ❖ how to verify execution of specific code
80. Using “Monkey Patching” ❖ can override almost anything ❖ the overrides are globally available… ❖ …so annotate tests to run in separate process
82. Mockery is awesome Kahlan is awesome
83. Having to test that a non-public method works is a testing smell
84. Having to test the contents and/or state of a protected attribute is a test smell
85. Verifying code got executed in your tests is EASY
86. You can use XDebug or new native support
87. Code coverage reports are criminally underused
88. I know we covered a lot of stuff
89. Maybe too much?
90. Shameless Self-Promotion https://leanpub.com/minimumviabletests http://grumpy-phpunit.com
91. Ways To Get In Touch ❖ email: chartjes@grumpy-learning.com ❖ Twitter: @grmpyprogrammer ❖ IRL: actually speak to me, I won’t hurt you
92. https://speakerdeck.com/ grumpycanuck/smelly-tests https://joind.in/14937