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

Chris Hartjes

April 14, 2016

More Decks by Chris Hartjes

Other Decks in Technology


  1. 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?
  2. What Do I Like To See? ❖ Dependency injection in

    use ❖ Small objects with few methods ❖ Bootstrapping that allows for easy overriding
  3. Don’t Lose Control ❖ Dependencies you cannot control means tests

    you cannot write ❖ Untested code can lead to weird bugs and unanticipated behaviour
  4. 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
  5. 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
  6. Taming Side Effects ❖ in-memory databases using SQLite ❖ in-memory

    file systems using vfsStream ❖ “dependency overloading” using Mockery
  7. In-Memory Databases ❖ Eliminates the side effect of modifying common

    databases ❖ Much better control over initial data sets
  8. 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
  9. “Using Test-Driven Development tends to result in large numbers of

    objects with small numbers of methods. Single responsibility principle in action!”
  10. 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
  11. 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?
  12. 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”
  13. Do You Understand The Tools? ❖ Do you know how

    to use the testing framework ❖ Do you know how test doubles work?
  14. “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.”
  15. Test Doubles “Use them when you have a dependency that

    is not under your control that needs to be in a specific state.”
  16. So What Should We Double? ❖ database connections ❖ code

    that calls 3rd party API’s ❖ code that has side effects
  17. 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
  18. 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?
  19. “As an aside, consider the use of contract-style tests as

    part of your integration test suite”
  20. Weird Stuff To Test ❖ dependencies that you cannot inject

    without risky refactoring ❖ getters and setters ❖ how to verify execution of specific code
  21. Using “Monkey Patching” ❖ can override almost anything ❖ the

    overrides are globally available… ❖ …so annotate tests to run in separate process
  22. Ways To Get In Touch ❖ email: [email protected] ❖ Twitter:

    @grmpyprogrammer ❖ IRL: actually speak to me, I won’t hurt you