Fake Your Test Away: How To Abuse Your Test Doubles, by Jenny Shih
Abstract
You probably already know: In a unit test, use test doubles to sub real dependencies. You probably also know: In reality, things are not so easy. What do you do if the dependencies span multiple layers? What if the dependencies are implicit? If we can't find the best level of isolation, test doubles can be unwieldy very quickly and they will make the test, as well as the future you, miserable. In this talk, we will look at symptoms that produce unreliable and unmaintainable tests, and develop a strategy that will make your test suite more resilient and actually enjoyable.
Detail
Include any pertinent details such as outlines, outcomes or intended audience.
This is my current outlines for the talk:
- Covering ground
- Terms definition
- Basic concepts
- Level of isolation
- Where things get tricky: A real example
- Faking the wrong layer
- Accidental fakes: Testing implementation details
- The butterfly effect
- Faking too much
- Helicopter programmer
- Fake empire
- Why do they happen?
- Something's wrong with your production code.
- Mixing decision with dependency
- The bottom line
- Don't panic
- What do I want this test to fail for?
- Definition of "unit"
- Reexamine your production code
This talk is designed for those who have some experience in software engineering and basic understanding of testing, but new programmers are welcome too as I'll be briefly covering the basics at the start. By the end of the talk, I hope the audience will be at a better position to write effective and maintainable tests.
Pitch
Explain why this talk should be considered and what makes you qualified to speak on the topic.
Test double is something that every programmer will encounter at some point in their career, and there are many resources on this topic. However, as plenty as those resources are, few of them touches on how and when to use test doubles beyond conveniently simple examples. In reality, there are many cases where the how and when to use test doubles are not so readily obvious.
I've been working with a codebase which serves millions of users worldwide per day. It has enough complexity for maintainers to produce tests that are seemingly functioning but actually brittle and ineffective. I've been exploring this topic for some time and I hope to share the mistakes I've made, what I've found, and the experiences I've gained.