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

Smelly Tests

Chris Hartjes
September 09, 2015

Smelly Tests

A rapid-fire look at the overall concepts surrounding writing effective unit tests and some tips on how to avoid tests that are as smelly as the code they are trying to protect

Chris Hartjes

September 09, 2015

More Decks by Chris Hartjes

Other Decks in Technology


  1. – talk description “You're now writing unit tests for your

    code...but you can't help but wonder if you are writing them the Right Way(tm). Given that learning to write good tests is no different from learning to write good code, it's inevitable that we make mistakes as we learn to create effective unit test suites.”
  2. So you’ve decided to write tests ❖ Is your code

    ready to test? ❖ Do you understand the testing tools? ❖ Do you understand common testing patterns?
  3. What Do I Like To See? ❖ Dependency injection in

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

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

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

    databases ❖ Much better control over initial data sets
  9. In-Memory Filesystems ❖ great for tests that need to read

    and/or write files ❖ no need to write code to clean up files after testing
  10. – some grumpy developer speaking to you “Using Test-Driven Development

    tends to result in large numbers of objects with small numbers of methods. Single responsibility principle in action!”
  11. 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
  12. 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?
  13. – a parent who hates repeating himself to his children

  14. – guy who never wishes for clones of himself “Just

    like duplicated code can be bad, duplicated tests can be bad.”
  15. Don’t Do 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”
  16. – developer who shouldn’t manage people “I’m sure I missed

    your favourite underused technique that is actually just lazy.”
  17. Do You Understand The Tools? ❖ Do you know how

    to use the testing framework ❖ Do you know how test doubles work?
  18. –Chris Hartjes “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.”
  19. Test Doubles – husband of the most patient woman in

    the world “Use them when you have a dependency that is not under your control that needs to be in a specific state.”
  20. So What Should We Double? ❖ database connections ❖ code

    that calls 3rd party API’s ❖ code that has side effects
  21. 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
  22. 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?
  23. – some guy who knows a thing or two about

    testing “As an aside, consider the use of contract-style tests as part of your integration test suite”
  24. Weird Stuff To Test ❖ dependencies that you cannot inject

    without risky refactoring ❖ getters and setters ❖ how to verify execution of specific code
  25. Using “Overloading” ❖ can override almost anything ❖ the overrides

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

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