TDD has long been recommended by agile practitioners, but the community still argues about how to go about it. Inside-out or outside-in? Mockist or classical? Through a component's public API or for every class? And then there's Kent Beck's famous quote: “I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.” This introduces a further level of subjectivity, especially since developers are frequently overconfident. In this session, Seb will explore the choices that agile teams need to make when considering which development practices to adopt. He'll look again at some of the arguments for the different approaches and urge teams to practice until you're happy with the way you code.

1. So
long,
and
thanks
for
all
the
tests
Seb
Rose
Claysnow
Limited
@sebrose
Friday, 26 September 14

2. Friday, 26 September 14

3. Why do we test software?
“a process of gathering information about
[software] with the intent that the information
could be used for some purpose”
Friday, 26 September 14

4. Developer tests
What are they for?
• making sure the code works
• preventing regressions
• documenting the code
• driving a testable design
Friday, 26 September 14

5. “I get paid for code that works, not for tests, so my
philosophy is to test as little as possible to reach a
given level of confidence ...
“I suspect this level of confidence is high
compared to industry standards”
http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565
Friday, 26 September 14

6. Developer testing
When do you write tests?
• never
• after writing the code
• while you write the code
• before writing the code
Friday, 26 September 14

7. Friday, 26 September 14

8. http://www.slideshare.net/sebrose/common-objections-to-tdd-and-their-refutations
Any objections?
Friday, 26 September 14

9. http://claysnow.co.uk/to-tdd-or-not-to-tdd/
To TDD or not to TDD?
That is NOT
the question!
Friday, 26 September 14

10. Friday, 26 September 14

11. Dreyfus model of skill acquisition
http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
Friday, 26 September 14

12. Friday, 26 September 14

13. Listen to your tests
Friday, 26 September 14

14. Friday, 26 September 14

15. Friday, 26 September 14

16. What is a unit test anyway?
A test is not a unit test if:
• It talks to the database
• It communicates across the network
• It touches the file system
• It can’t run at the same time as other
unit tests
• You have to do special things to your
environment (such as editing config
files) to run it
http://www.artima.com/weblogs/viewpost.jsp?thread=126923
Friday, 26 September 14

17. http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/
Test behaviours not implementation details
“When we refactor we don’t want to break tests. If
our tests know too much about our
implementation, that will be difficult, because
changes to our implementation will necessarily
result in us re-writing tests – at which point we are
not refactoring.We would say that we have over-
specified through our tests.
Instead of assisting change, our tests have now
begun to hamper it.”
http://vimeo.com/68375232
Friday, 26 September 14

18. Properties of unit testing
Understandable
Maintainable
Repeatable
Necessary
Granular
Fast
Friday, 26 September 14

19. Q. How can we test components in isolation?
A. Seams
Friday, 26 September 14

20. The Meszaros taxonomy
http://xunitpatterns.com
■Dummy objects are passed around but never
actually used.
■Fake objects have working implementations.
■Stubs provide canned responses'.
■Mocks are pre-programmed with expectations
which form a specification of the calls they are
expected to receive.
Friday, 26 September 14

21. Mocking in a nutshell
Friday, 26 September 14

22. Mocking can make a terrible mess
Friday, 26 September 14

23. Mocking can give you a false sense of security
via JB Rainsberger, GOOS mailing list,“Unit-test mock/stub assumptions rots”, 15 March 2012
Friday, 26 September 14

24. How valuable are your tests?
Friday, 26 September 14

25. http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html
Friday, 26 September 14

26. http://www.slideshare.net/dannorth/accelerating-agile-testing
Friday, 26 September 14

27. http://www.slideshare.net/dannorth/accelerating-agile-testing
Friday, 26 September 14

28. http://pitest.org
Mutation testing
Friday, 26 September 14

29. Friday, 26 September 14

30. Friday, 26 September 14

31. Developer tests - recap
What are they for?
• making sure the code works
• preventing regressions
• documenting the code
• driving a testable design
Friday, 26 September 14

32. Things that seem important to me:
- chase the VALUE
- identify the RISKS
- understand your CONTEXT
The tests should make your life EASIER
Friday, 26 September 14

33. Seb
Rose
Twi;er:
@sebrose
Blog:
www.claysnow.co.uk
E-­‐mail:
seb@claysnow.co.uk
Seb Rose,
Available Now
in beta
Friday, 26 September 14