You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It could be nice to have an assist for generating a test stub, for example
#[test]fntest_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.
pubstructRay{puborigin:Vec3,pubdirection:Vec3,pubtime:Float,}implRay{// ...pubfnpoint_at_parameter(&self,t:Float) -> Vec3{self.origin + t *self.direction}// ...}
and autogenerating e.g. something along the lines of
#[test]fntest_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.
The text was updated successfully, but these errors were encountered:
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.
Similar to #3639
Main idea, briefly:
After writing a function declaration
It could be nice to have an assist for generating a test stub, for example
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.
and autogenerating e.g. something along the lines of
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 theVec3::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.
The text was updated successfully, but these errors were encountered: