Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Grumpy Testing Patterns

Grumpy Testing Patterns

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

27601bca8f38e75cbcf9d2dc843f0b32?s=128

Chris Hartjes

April 14, 2016
Tweet

Transcript

  1. Grumpy Testing Patterns Chris Hartjes PHP Australia Conference April 15,

    2016
  2. None
  3. None
  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

  8. None
  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?
  11. None
  12. What Do I Like To See? ❖ Dependency injection in

    use ❖ Small objects with few methods ❖ Bootstrapping that allows for easy overriding
  13. None
  14. None
  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
  18. None
  19. None
  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
  22. None
  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
  24. None
  25. None
  26. None
  27. None
  28. Small objects with few methods

  29. None
  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?
  34. None
  35. None
  36. None
  37. For those counting along: 24 lines of setup 5 lines

    of tests
  38. None
  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

  42. None
  43. None
  44. None
  45. “DO YOU NOT NOTICE HOW SIMILAR ALL THESE TESTS ARE?!?.”

  46. None
  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.”
  67. None
  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
  78. None
  79. None
  80. Using “Monkey Patching” ❖ can override almost anything ❖ the

    overrides are globally available… ❖ …so annotate tests to run in separate process
  81. None
  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