Implement proposed changes to generator#538
Conversation
bd62c04 to
c351698
Compare
|
Note on the checklist; the first item says "My code follows the style guidelines of this project", but I haven't actually found any style guidelines in the repo. I tried to match the style of the code around where I made modifications. I also didn't add any comments, as the sections of code that I was modifying already didn't contain any. I can add some comments around the new bits if you prefer. |
c351698 to
5440b18
Compare
|
@dlwyatt Do you know whether it is going to be merged or know someone who we can ask if they are going to merge? Should we ask it to @LandonTClipp? |
|
No idea. 🙂 This is my first interaction on this project. |
|
Hi folks, thanks for the contribution. I will have to review the proposed change over the coming days. I work a full-time job so I can't commit to a specific period but I do try my best so I hope to have at least a first pass review by the end of this week :) |
Codecov ReportBase: 71.90% // Head: 72.59% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #538 +/- ##
==========================================
+ Coverage 71.90% 72.59% +0.69%
==========================================
Files 6 6
Lines 1242 1277 +35
==========================================
+ Hits 893 927 +34
- Misses 305 306 +1
Partials 44 44
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| g.printf("%s\tif rf, ok := %s.Get(%d).(func(%s) %s); ok {\n", | ||
| tab, retVariable, idx, strings.Join(params.Types, ", "), typ) | ||
| g.printf("%s\t\tr%d = rf(%s)\n", tab, idx, formattedParamNames) | ||
| g.printf("%s\t} else {\n", tab) |
There was a problem hiding this comment.
You know a part of me wants to stop using individual printf statements because it's difficult for me to understand what's going on. You have the right approach of trying to follow what the code historically did, but I think it'd be better for readability to use the printTemplate method instead. What do you think? Is that easily done or is printf a better fit here?
There was a problem hiding this comment.
I don't find either of them all that easy to follow, tbh. It's easier to look at the expected outputs in generator_test.go, and trust the tests to make sure all the templates and printf's are actually producing that.
There was a problem hiding this comment.
Comparing before and after on one of the test cases, this PR changes this:
// Put provides a mock function with given fields: path
func (_m *RequesterReturnElided) Put(path string) (int, error) {
ret := _m.Called(path)
var r0 int
if rf, ok := ret.Get(0).(func(string) int); ok {
r0 = rf(path)
} else {
r0 = ret.Get(0).(int)
}
var r1 error
if rf, ok := ret.Get(1).(func(string) error); ok {
r1 = rf(path)
} else {
r1 = ret.Error(1)
}
return r0, r1
}into this:
// Put provides a mock function with given fields: path
func (_m *RequesterReturnElided) Put(path string) (int, error) {
ret := _m.Called(path)
var r0 int
var r1 error
if rf, ok := ret.Get(0).(func(string) (int, error)); ok {
r0, r1 = rf(path)
} else {
if rf, ok := ret.Get(0).(func(string) int); ok {
r0 = rf(path)
} else {
r0 = ret.Get(0).(int)
}
if rf, ok := ret.Get(1).(func(string) error); ok {
r1 = rf(path)
} else {
r1 = ret.Error(1)
}
}
return r0, r1
}And adds this to the expecter calls:
func (_c *RequesterReturnElided_Put_Call) RunAndReturn(run func(string) (int, error)) *RequesterReturnElided_Put_Call {
_c.Call.Return(run)
return _c
}There was a problem hiding this comment.
I think we can merge this but I would like to use the printTemplate method instead just for maintainability/readability sake. If you can make that change then I'll merge this PR. This is a really good change but that's my only ask at this point. Everything else is good.
There was a problem hiding this comment.
I can try, but that's a heck of a lot more work to rewrite more of the code than what I've modified so far, and getting templates to produce exactly the same output might be pretty annoying.
There was a problem hiding this comment.
This is great! Sorry, if I knew how much of a pain it would be maybe I could have let it slide but I do really enjoy the templates a lot more. At least to me, it's easier to reason about.
I'll ack this, lmk if there are any finishing touches you want to make before I merge.
There was a problem hiding this comment.
I need to walk away for a bit and look at it with fresh eyes later, maybe in the morning. I'll let you know if I spot anything that could use work then.
There was a problem hiding this comment.
Sounds good, thanks for the stellar work. It's really appreciated.
There was a problem hiding this comment.
I think this is good to go. There was one function comment that was sort of inaccurate after I changed things, but I think the code itself is okay.
There was a problem hiding this comment.
Great work, I’ll take one last look tonight and merge if everything is good. Thanks Dave.
Description
Allows a single provider function to be used which provides all of the return parameters for a mocked function, instead of needing to define a separate function per output. The older functionality still works as well.
Also adds a new RunAndReturn function to expecter calls to use this same type of provider, functionally equivalent to
.Call.Return(providerFunc)Type of change
Version of Golang used when building/testing:
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Updated generator_test.go and ran
make test. Was not able to runmake allon my system, something about therun-e2e.shscript didn't work for me. (I'm running Ubuntu in WSL on Windows 11, if it matters.)I also ran the new build against some of my own test code, such as the samples in #537 , to make sure the generated code behaved as expected when
go testwas run.Checklist