-
Notifications
You must be signed in to change notification settings - Fork 413
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
unnecessary mock for type definition of func #716
Comments
Mockery can mock plain functions. What's your config? I wouldn't say this is unexpected. |
Thanks for your reply. This is my config: with-expecter: false
all: true
filename: "{{.InterfaceNameSnake}}.go"
outpkg: mock{{.PackageName}}
mockname: "{{.InterfaceName}}"
dir: test/mock/{{trimPrefix .InterfaceDirRelative "pkg/"}}
packages:
packageNameA:
config:
recursive: true Is there any way to skip mock for plain functions? |
+1 |
Semantically speaking, mockery is doing the correct thing as functions are capable of being mocked. However the issue is the use of an unexported struct as you mentioned. From mockery's perspective, this is expected behavior in the sense that you're asking it to generate mocks outside of the original package for a function that uses an unexported struct, which won't compile, but it's what you asked it to do. The way to fix this in my opinion is either:
The first point should probably be added anyway, but it's a bandaid for this particular problem. The second point is the most generalizable. The third already works now but it's manually intensive. The issue is not specific to function types, you would run into the same problem if your interface referenced unexported types. |
Maybe option to filter type signature would be more flexible. Like |
where do I find this in the docs? |
https://vektra.github.io/mockery/latest/examples/#function-type-case This is feature was made shortly after I took over the project but I feel like it was an unnecessary addition, and it doesn't seem like it was ever a widely-used feature anyway. While mockery can support this, I encourage people not to and instead just create your own function implementations. The old pre-packages config semantics natively support function mocking but I never made an attempt to make it work for |
Hi @LandonTClipp , I was also having this issue, but something doesn't feel right. I have the following created in a top level go file, and it creates a mock, but if you notice, it is NOT exported.
According to the rules, I would have expected Ringmenow to be mocked as it is exported, but my func which is not exported (ringmenow) shouldn't be? Is my assumption right ? I will place the mock that is created below for visibility Thanks in advance Ian
|
I'm trying to switch (again) to package config, but I get these mocks for functions generated out of blue. The old pre-package config didn't seem to generate them. So you are saying they are not working with package config, yet somehow they get generated? While I never got them generated with pre-package config? Fishy. |
Helps with vektra#716
v2.45.0 adds the config option |
Thanks! It works! |
Description
When using the designing pattern of Option Pattern, there will be some code below:
mockery
will produce code below:It import a unexported struct. Is it a expected behavior? IMO,
mockery
should not produce a mock forfooOptions
as it is not a interface.Mockery Version
v2.34.0
Golang Version
1.20
Installation Method
Steps to Reproduce
Expected Behavior
[what you expect to happen]
Actual Behavior
[what actually happened]
The text was updated successfully, but these errors were encountered: