One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. Being able to influence this type of testing in a positive manner is a skill that testers will need to get to grips with, as more companies start to embrace a model of lone testers in cross functional teams. The shift of focus from primarily the testing that testers do, to the testing that the team does, is a key shift in thinking and behaviour. To facilitate this shift, I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers and help us realise what other layers of testing can cover most effectively. The last point is pertinent here, as knowing and guiding unit testing brings the role of integration, acceptance and exploratory testing into sharp focus. This is a topic that has always intrigued me, having predominantly worked as a single tester on a team for the last five or so years. I reached out to the community with the question “What do testers believe about unit testing?” and received a lot of engagement. The good users of Twitter added another 50 or so illusions that testers might have about this layer of testing. I figured that based on that level of engagement, maybe this would make an interesting talk! It wasn’t only testers who responded too, suggesting that there might be some shared illusions about unit testing that are cross disciplinary. The list alone is interesting but now I would like to share my analysis of it with you, focusing on: * Recurring themes within the list and how to address them as a tester or developer. * Particular illusions to look out for with examples from my recent past. * A guide for developers to engage with testers on unit testing, and testers with developers.

1. “Myths which are believed in tend
to become true.” ~ George Orwell

2. Ash Winter
Short stuff here:
@northern_tester
Long stuff here:

3. A Testers* Guide to the Illusions
of Unit Testing
* Disclaimer: this definitely maybe applies to all disciplines in software
development, not only testers but I’m a tester so its from my point of view.

4. This is Gus
• Speakeasy
• Great
mentor
• Taught me
speaking
wasn’t only
about me

5. Tweet

6. Blog

7. Talk

8. • Lone testers
• Testers as
coaches
• Testing in
other layers
• Sum of all
testing
• Cross
discipline
illusions
Y Tho?

9. • Reactions
• Tyranny of
pyramids
• What is a
unit?
• Colin’s
Pop Quiz…
• Toolkits
Coming up…

11. Goonies
• Testing meetup
• Strategy without unit tests
• I shut them down…

12. Word
• “I’ve
written my
unit test
plan.”
• O rly…?
• But they
were
testing

13. Reactions
• Your scenarios
• In pairs
please
• One scenario
each
• Positive
responses –
start dialogue
• Negative
responses –
shut downs

14. Now a word from the sponsors of
most unit testing illusions…

15. • Useful frame of reference?
• Dogma justifying blood sacrifice?
• Source of many illusions…
That Pyramid…

16. • That unit tests fill in the bottom of the
pyramid
• That unit tests remain in the bottom layer of
the pyramid
• That unit tests are inherently more valuable
than other layers of tests
• That unit test coverage is irrelevant to
manual testing
• Large number of unit tests can replace
integration tests.
• You don't need additional tests because
everything is unit tested
• If you have a suite of unit tests you don't
need to do much other testing
The Pyramid…

17. • Do unit tests
supersede all
other forms of
testing?
• Still deliver what
someone that
matters wants?
• Get in their shoes
• Time to make
empathy our
superpower…
Could it be true?

18. • Pairs or
threes
• Large sheet
of paper
• Lets empathy
map
• (2 or 3
sections)
I know those feels

19. Belief: If you have unit tests, you don’t need to invest (too
much) in other forms of testing…

20. Existential Questions
• Existence == good
• Tests exist to find bugs
• Unit tests communicate intent
• What’s a unit?

21. What is a unit then?
• “That
there is a
unit to
test”
• Method?
• Class?
• Service?
• How to
find the
unit?

22. Reinventing the wheel…

23. For example…
Microservice
Single
Database
Multiple
Applications
Broker/Queue
Based

24. More group work…
• Pairs or
threes
• Unit Owner
• Draw the
wheel, if
it helps
• Wheel and
supporting
notes

25. • What factors
help to find
a unit of
your system?
• What
practices &
patterns
influence
that unit?
• How
practices
and patterns
govern size
of a unit?

26. Pop Quiz Hotshots
• Devs always
write them
• Devs never
write them
• Testers
shouldn’t
write them
• What does
good look
like…

27. Colin
Friends of Ilkley Moor

28. Bad?

29. Atomic?

30. Trustworthy?

31. Readable?

32. Structured?

33. • Help find out what a unit is
• Do some TDD
• Lens into the assumptions & bias
• Question assertions
• Anything else?
As a tester

34. • Integrate with
the test
strategy
• Code coverage
!= test
coverage
• Pair on writing
unit tests
• Anything else?
Help from devs

35. Thanks