Parametrized tests

This is a survey/question topic.

Recently, I'm finding myself in a situation where I want to test an interface (e.g. a trait). The way I do it right now is to setup a dummy/mock object which implements it, and then use it in the test suite (possibly wrapping it in Box<dyn TheTrait>).

However, what if I wanted to create a separate crate with a different implementor of the tested trait? I would need to transfer the test suite manually, which isn't ergonomic. I want to write the tests for a generic type implementing TheTrait and then instantiate the tests for a particular implementation.

The hypothetical ways of doing this that come to my mind are:

  1. generic modules (the module arguments get expanded into local type aliases)
  2. allowing testing traits (the test cases are declared as the trait's associated functions and are run on a particular impl)

What do you think about this, and which ways would you test an interface?

Personally at this moment, I'd write a function or macro that takes as parameters whatever differs between those tests, put that in a separate crate, and just use it where appropriate as a dev-dependency.

4 Likes