Hello
I know there’s a discussion about allowing custom test frameworks to get integrated. But most of the time the default one is just good enough solution ‒ it feels friendly, lightweight and not opinionated.
However, I often find myself writing code like this:
struct TestData {
/* Something goes in here */
}
impl Default for TestData {
fn default() -> Self {
TestData {
/* Something goes in here */
}
}
}
#[test]
fn do_test() {
let test_data = TestData::default();
/* do stuff with the data */
}
/* More tests with the TestData */
Basically, this is poor man’s test fixture ‒ it has a setup (the Default) and optionally teardown (Drop). And I had this idea how to make it more comfortable. If a data type implements Default, it could be passed as a parameter to the test function. (more different fixtures could be allowed) The test harness would create the fixture and pass it in. self would be just a special case, so one could write:
#[test]
fn do_test(test_data: &TestData) {
...
}
or even:
impl TestData {
#[test]
fn do_test(&self) {
...
}
}
To me, it feels quite natural extension of what exists already. It is probably only convenience. Now, my questions are:
- Does this idea pose some serious problem I overlooked?
- With the coming (hopefully) of allowing custom test frameworks, is the built-in „sealed“, or would it be possible to extend it?
- Does anyone but me see a value in such a thing?
- How hard would it be to implement something like this (provided enough people find it interesting, I write a real RFC about it, it goes through…)? I’d like to know if it would be worth the effort, or if it is just too much work for little gain.
