vektra / mockery

A mock code autogenerator for Go
https://vektra.github.io/mockery/
BSD 3-Clause "New" or "Revised" License
5.8k stars 395 forks source link

Added InterfaceFile #773

Closed istrau2 closed 2 months ago

istrau2 commented 2 months ago

Description

Added InterfaceFile to available fields in .mockery.yaml template

I would like to name the mock file similarly to the interface file. Currently there is no way to know the interface file name in the template.

Type of change

LandonTClipp commented 2 months ago

Hey, thanks for the PR! This parameter would be potentially misleading because you might have multiple interfaces within a single file. People have asked this before and I mention it only works in the case where you have one interface per file.

istrau2 commented 2 months ago

@LandonTClipp Thanks for the quick response.

I understand the concern, however, as far as this package is concerned I don't see how this is misleading. It is in fact the name of the file that the interface is in. If the consumer has decided to name their mock files based on the original name, they should ensure that there is only one interface in each file. Otherwise, as I understand, it would be overwritten, that seems fairly clear (and frankly, would be immediately observed since the tests would break).

For us, we have been happily using mockery for a couple of years now. Recently we've been getting deprecation warnings and I've been trying to upgrade to the new configuration. We do in fact have one interface per file and use a file name like interface_file_mock.go alongside the original interface_file.go all throughout the codebase. I would like to upgrade in a backwards compatible manner (rather than having to rename/restructure the codebase).

Perhaps a warning is in order if two interfaces share the same file name (although I am not sure how to implement that)?

Thanks again

LandonTClipp commented 2 months ago

I've thought about this a bit more and in order to help you migrate to the new config, I think we can go ahead with it. My main concern is that it causes confusion without making an explicit note in the docs about what the behavior is when multiple interfaces are in a single file. I will just make a note in the docs to make this clear.

The other consideration I am making is that I will, at some point, implement supporting multiple interfaces per mock file, and the intention was to use this exact config parameter in this PR to support that. I can't conceive of any issues with introducing multi-interface support into projects that make use of this parameter. It might cause mocks to magically appear where they otherwise would not, but again, making this clear in the docs is the right way forward.

LandonTClipp commented 2 months ago

@istrau2 could you please add a test for this to ensure that the rendered template matches what we expect? Once you get that, I can approve.

istrau2 commented 2 months ago

@LandonTClipp Much appreciated, thanks a lot. I have added the test.

istrau2 commented 2 months ago

@LandonTClipp thoughts?

LandonTClipp commented 2 months ago

Looks great!