Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ETC (European Testing Conf) 2019: How to Stop Testing and Break Your Code Base.


Published on

Do you code on your own? When you do, do you write unit tests? Do you aim for test-driven development?

Recently, Sal Freudenberg and I have been remote-pairing on an iOS puzzle app. I love to play this game we’re building, which makes me not only software engineer but also end user, product owner, business stakeholder, and everything else. As a user I wanted new features and I wanted them NOW. I didn’t care about the tests - I just wanted a better game!

The reason I asked Sal to join me is that my testing strategy was getting increasingly lax, and the quality of the code was suffering. The increasing lack of tests made the code harder and harder to extend.

I stopped testing for bad reasons, but started again for good ones. The experience has allowed me to demonstrate in practice the impact it can have on your code base when you don’t test, and also when you do. This talk, based on simple practical examples, will explain exactly why unit tests, a TDD approach and pairing can make all the difference to your code.
From this conference:

Published in: Technology
  • Be the first to comment

  • Be the first to like this

ETC (European Testing Conf) 2019: How to Stop Testing and Break Your Code Base.

  1. 1. How to Stop Testing @ClareSudbery …and break your code base
  2. 2. My name is Clare and I am a bad person…
  3. 3. SquareFill
  4. 4. The game is not just to play the game, it is to make the game better… and the code!
  5. 5. WOT NO TESTS??
  6. 6. Giving the finger (“Yeah, f*ck you!”)
  7. 7. A lack of tests causes PAIN • Refactoring • Encapsulatio n • Spikes • Design
  9. 9. Is (0, 0) the top left corner or the top left square? CAN’T REFACTOR Is this pointing at (0, 6) or (0, 192)?
  10. 10. Things get in the way
  12. 12. “The essence of encapsulation is turning a design decision into a secret.” - Martin Fowler
  13. 13. “Modules should be arranged around system secrets, each module hiding its secret from the other modules. Then if the secret thing changes, you avoid a ripple effect.” - Martin Fowler
  14. 14. OVER-RELIANCE ON ACCEPTANCE TESTS GameGenerator.ShuffleShapes
  15. 15. It's better to break encapsulation principles to get tests in place, than it is to break testing principles to keep encapsulation in place.
  16. 16. Don’t wait for the race-track to test the car
  17. 17. Example: the danger of spikes
  20. 20. MY NEW PAIR
  22. 22. • No tests = false economy • Not running tests = false economy • Tests facilitate refactors • Tests before refactoring • Acceptance = not enough • Write new tests in response to new problems • Keep everything green • Pairing keeps you honest • (3 more slides)
  23. 23. Landing in a neat pair-synchronized way. Qg
  24. 24. That’s enough now….
  25. 25. THANK YOU
  26. 26. (the end)
  27. 27. BLANK SLIDE
  28. 28. Blank slide with more text
  29. 29. Blank slide with more text
  30. 30. How to Stop Testing @claresudbery …and break your code base
  31. 31. How to Stop Testing @claresudbery …and break your code base
  32. 32. How to Stop Testing @claresudbery …and break your code base