Skip to content

Feature request: Assist - Generate test stub #9566

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Walther opened this issue Jul 11, 2021 · 1 comment
Open

Feature request: Assist - Generate test stub #9566

Walther opened this issue Jul 11, 2021 · 1 comment
Labels
A-assists S-actionable Someone could pick this issue up and work on it right now

Comments

@Walther
Copy link
Contributor

Walther commented Jul 11, 2021

Similar to #3639

Main idea, briefly:

After writing a function declaration

pub fn weird_algorithm(start: usize) -> String {
  todo!()
}

It could be nice to have an assist for generating a test stub, for example

#[test]
fn test_case_1() {
    let result = weird_algorithm(start);
    let expected = "";
    assert_eq!(result, expected);
}

It would then be easy for the user to fill in the desired parameter and result values.

This could be especially helpful for functions with more parameters, and possibly complex structs as input. Imagine e.g.

pub struct Ray {
    pub origin: Vec3,
    pub direction: Vec3,
    pub time: Float,
}

impl Ray {
// ...
    pub fn point_at_parameter(&self, t: Float) -> Vec3 {
        self.origin + t * self.direction
    }
// ...
}

and autogenerating e.g. something along the lines of

#[test]
fn test_case_1() {
    let origin = Vec3::new();
    let direction = Vec3::new();
    let time = 0.0;
    let ray = Ray {
        origin,
        direction,
        time,
    };
    let t = 0.0;
    let result = ray.point_at_parameter(t);
    let expected = Vec3::new();
    assert_eq!(result, expected);
}

Of course there would be a lot of details to figure out here - how much would we want to unroll parameters into new variables on separate lines vs. keeping them inline, would we want the autogenerated code to prefill values like 0.0 above, do we want to assume initializers (like the Vec3::new() above) and prefill those for the more complex structs, or do we want to just use () like e.g. the current "Fill struct fields" autogen does as the simplest possible prefill, etc. Please don't judge these code examples as exact suggestions - feel free to figure out improved ideas.

On a conceptual level, I feel like the autogenerated code doesn't have to be perfect. Writing the initial case for the first time can be a bit annoying / tedious, but for the next test cases it's fairly easy to copy-paste the entire test and modify some values. Getting a placeholder generated with somewhat correct parameters prefilled would be a nice quality-of-life improvement. And of course making it as useful as possible could be a nice stretch goal.

@lnicola lnicola added A-assists S-actionable Someone could pick this issue up and work on it right now labels Jul 11, 2021
@ckaran
Copy link

ckaran commented Mar 10, 2022

I'd like to take this a step further (if it's possible). For anything that is marked pub, I'd like to see stub code placed in the tests, benchmarks (ideally using criterion, and examples directories. That should help developers (including me!) remember that pub means that it's part of the public API, which means that should be tested, properly documented, etc., etc., etc.

I have no idea if that is even possible though as those files should be in the crate, but are likely to be in files different from the one that the analyzer is currently working within.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-assists S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

No branches or pull requests

3 participants