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

The Cartography of Testing: CodeMash 2015

The Cartography of Testing: CodeMash 2015

Developers writing tests is now very very common. But testing remains a big, confusing, and controversial topic. This talk attempts to take a fresh look at testing, and try to get at a deeper more nuanced understanding of it. So even if you do TDD every day, hopefully you’ll come away with a refreshed and invigorated perspective.

Kevin Berridge

January 08, 2015
Tweet

More Decks by Kevin Berridge

Other Decks in Programming

Transcript

  1. –Practical Object-Oriented Design In Ruby “The true purpose of testing,

    just like the true purpose of design, is to reduce costs.”
  2. –Code Complete “It is cheaper to build high- quality software

    than it is to build and fix low-quality software.”
  3. –Software Test Automation “Run more often. Runs tests that are

    difficult or impossible manually. Better use of resources. Consistency & repeatability.”
  4. –Software Test Automation “The true value of automated tests is

    often in providing confidence rather than finding defects.”
  5. –@ChrisOldwood, Twitter “Not refactoring after making a code change is

    like putting an empty cereal box back in the cupboard.”
  6. –Refactoring “Whenever I do a refactoring, the first step is

    always the same. I need to build a solid set of tests for that section of code. The tests are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I'm still human and still make mistakes. Thus I need solid tests.”
  7. –Clean Code “It is unit tests that keep our code

    flexible, maintainable, and reusable." "If you have tests, you do not fear making changes to the code!”
  8. –Clean Code “Code without tests is bad code. It doesn't

    matter how well written it is; it doesn't matter how pretty or object-oriented or well- encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.”
  9. –Growing Object-Oriented Software “We need to keep the code as

    simple as possible, so it's easier to understand and modify. …Simplicity takes effort, so we constantly refactor our code as we work with it. …The test suites in the feedback loops protect us against our own mistakes as we improve (and therefore change) the code.”
  10. –Practical Object-Oriented Design In Ruby “The art of writing changeable

    code requires the ability to write high-value tests. Tests give you confidence to refactor constantly.”
  11. TESTS ARE THE BEST AND CHEAPEST TOOL WE HAVE TO

    MANAGE FEAR AND REPLACE IT WITH CONFIDENCE
  12. –Test-Driven Development “My goal is to feel better about a

    project after a year than I did in the starry-eyed beginning, and TDD helps me achieve this.”
  13. –Working Effectively With Legacy Code “Unit testing is one of

    the most important components in legacy code work. System-level regression tests are great, but small, localized tests are invaluable. They can give you feedback as you develop and allow you to refactor with much more safety.”
  14. –Working Effectively With Legacy Code “The feedback we get from

    [testing] is very useful. It pays to [test] at a finer- grained level.”
  15. –Growing Object-Oriented Software “If we test at too large a

    grain, the combinatorial explosion of trying all the possible paths through the code will bring development to a halt.”
  16. –Working Effectively With Legacy Code “There are a few problems

    with large tests: Error localization, Execution time, Coverage”
  17. –Working Effectively With Legacy Code “There are a few problems

    with large tests: Error localization, Execution time, Coverage”
  18. –Growing Object-Oriented Software “We start work on a new feature

    by writing failing acceptance tests that demonstrate that the system does not yet have the feature we're about to write and track our progress towards completion of the feature.”
  19. –Mike Bland, http://martinfowler.com/articles/testing-culture.html “You should not be catching bugs at

    the integration or system levels that could have been caught at the unit level.”
  20. T O

  21. –Sandi Metz “I examine the original test and morph it

    from an integration test into an actual unit test.”
  22. –Growing Object-Oriented Software “…investigate why the test is hard to

    write and refactor the code to improve its structure. We call this 'listening to the tests.'”
  23. –Practical Object-Oriented Design In Ruby “Tests are the canary in

    the coal mine; when the design is bad, testing is hard.”
  24. –Growing Object-Oriented Software “We've found that the qualities that make

    an object easy to test also make our code responsive to change.”
  25. –Working Effectively With Legacy Code “Dependency is one of the

    most critical problems in software development. Much legacy code work involves breaking dependencies so that change can be easier.”
  26. –Working Effectively With Legacy Code “When classes depend directly on

    things that are hard to use in a test, they are hard to modify and hard to work with.”
  27. –Practical Object-Oriented Design In Ruby “Dealing with objects as if

    they are only and exactly the messages to which they respond lets you design a changeable application, and it is your understanding of the importance of this perspective that allows you to create tests that provide maximum benefit at minimum cost.”
  28. –Kent Beck “Separate interface from implementation thinking. I have a

    tendency to pollute API design decisions with implementation speculation.”
  29. –Practical Object-Oriented Design in Ruby “Some outgoing messages have no

    side effects… Outgoing messages like this are known as queries and they need not be tested by the sending object.”
  30. –Practical Object-Oriented Design in Ruby “Many outgoing messages do have

    side effects… These messages are commands and it is the responsibility of the sending object to prove that they are properly sent.”
  31. –Growing Object-Oriented Software “For TDD to be sustainable, the tests

    must do more than verify the behavior of the code; they must also express that behavior clearly -- they must be readable.”
  32. –Clean Code “The dirtier the tests, the harder they are

    to change… So the tests become viewed as an ever- increasing liability.”
  33. –Growing Object-Oriented Software “We want our test code to read

    like a declarative description of what is being testing.”
  34. –Growing Object-Oriented Software “We want to make sure the tests

    pull their weight by making them expressive, so that we can tell what's important when we read them and when they fail”
  35. –Software Test Automation “Test cases must be designed with debugging

    in mind by asking 'What would I want to know when this test fails.’”