Sometimes, what you need is a parameterized test. They do the job of representing a single way of testing with an input table full of use cases and expected outcomes.
In some ways, a test suite is just a set of inputs and expected outputs, but a parameterized test is one where the execution of the test is pretty uniform.
It may be tempting to handle subtle variants in parameterized tests by putting some conditional logic in a generic test, fed loads of diverse inputs, but be wary of that.
If You Don’t Use Parameterized Tests
You’re missing out on:
- Expressing groups of related tests in a more structured way
- Using the table of inputs/outputs as a way to help you spot gaps in your tests, think up more use cases, and cheaply add them
- Less test code to maintain
Do I Need A Parameterized Test?
- A family of tests have the same test code
- The names of the tests end up with
_example2or similar on them – suggesting that you’re having a test naming problem, but also suggesting that there’s no real distinction between the use cases, other than the data
But… if there’s only a 2 or 3 examples, then perhaps the parameterized test is overkill.
What Do They Look Like?
An example in JUnit 5: