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.
Include any pertinent details such as outlines, outcomes or intended audience.
This is my current outlines for the talk:
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.
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.