Testers Guide to the Illusions of Unit Testing
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Semelhante a Testers Guide to the Illusions of Unit Testing
Semelhante a Testers Guide to the Illusions of Unit Testing (20)
Mais de Ash Winter
Mais de Ash Winter (20)
Último
Último (20)
Testers Guide to the Illusions of Unit Testing
- 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?
- 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
Notas do Editor
- Class
- Class
- Class
- Class
- Class
- use of a loader to set up a database… so the database needs to exist and be running on the environment the test is running in contents of the database can be changed by config changes our desired test behaviour is overriding some kinds of database lookup anyway
- use of a loader to set up a database… so the database needs to exist and be running on the environment the test is running in contents of the database can be changed by config changes our desired test behaviour is overriding some kinds of database lookup anyway
- Atomic - runs alone without needing other tests to run before or after. Excessively simplified to prove the point - the testMultiplyValue will fail if run alone, unless the class actually has “15” as a default value, in which case the first test is useless.
- Trustworthy - runs anywhere - dev machine, docker container, CI flow. Should not depend on external processes, particular paths etc.. setting up all the dependencies itself. This example seems straightforward, but will fail if the timezone is ‘America/Los_Angeles’ for example.
- Readable - can you work it out just by reading. This example fails on both fronts, with mixed tabs and spaces, inconsistent indents, poor variable naming, spelling issues and bad test names (to be fair to the author of the test I used as an example here, the formatting, variable names and spelling I’ve deliberately made much worse, but the original isn’t still hard to understand)
- Notes: Next, something much clearer: If you can clearly break your test up into these sections it will be more readable. 1,2 setup 3 execute 4 verify 5,6 teardown It seems obvious, but some of this often gets mixed up - and is not always clear.
- NO QUESTIONS, HAVE A BEER.