The false dichotomy of tests
It’s a conversation which seems to crop up again and again, and provoke a mixture of assumptions and opinions. Here’s Gojko Adzic‘s take on what is a unit test, and what is an acceptance test.
Gojko Adzic » The false dichotomy of tests.
For me, an “acceptance test” is a concrete expression of one or more particular acceptance criteria, typically formulated as a story or use case with explicit (and ideally customer-supplied) values. Everything else is is just a (development) test, regardless of how much or how little of the system it exercises. I see no particular value in separate names and arguments over whether something is a “unit” test, an “integration” test, a “story” test, or whatever.
There are two dimensions involved here, aren’t there? There’s what’s tested, and why. And I think that ‘unit’ and ‘acceptance’ alone don’t really cover the subject.
Clearly, ‘unit testing’ is now too overloaded to be used without care. I’d say the majority of developers mean ‘mostly single class testing inside a single runtime process’. For people like that, I don’t think there’s a word for testing collaborations of multiple classes, and it’s often seen as a Bad Thing – because it tests too much, apparently – unless it’s called SpringContextTest
There are other kinds of testing which do need to be identifiably separate, and for which it would be nice to have a common vocabulary. I know that because I keep hearing – and being involved in – discussions in which people think they’re talking about the same thing but aren’t. In any reaonsable complex enterprise system comprising multiple deployable components (I know that phrase could do with unpicking, but can we let it ride?) deployment is complex – so it’s useful to be able to test individual deployable components (component testing) and multiple components strung together (integration testing) and of course all components under your control (system testing). Each of these activities is worthwhile, and each has different complexities and pressures, and each happens in general at different parts of the workflow or on different timescales, unless you’re lucky enough to have a blazingly fast continuous delivery ecosystem.
The other dimension, which is more about ‘why’ rather than ‘what’, identifies the primary stakeholder. And there things are equally messy, and there’s equally little shared vocabulary. Here particularly, things have become so confused that the words are nearly useless except as team-specific monikers. I think the most important thing is that a team agree on terminology early on, and be honest about resolving ambiguities.