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
First off, this module is absolutely sublime. Wonderfully convenient for developers to use. Absolutely stellar job creating the developer-facing API! This should be the number one mocking module for Gophers!
The only shortcoming I experience is as follows:
My common workflow with this module, is to generate a bunch of mocks from my interfaces, and then, for some, but not all of the mocks, create a custom wrapper function that first calls the generated constructor function, then assigns a bunch of default returns or default hooks, and return the result. This allows for a super simple way of getting a mock with sensible defaults inside of a unit test (and optionally further change some of the hooks to simulate the scenario that you want to test).
I'd like to keep these custom constructors in the same package as the mock objects, and then apply the NewMock**** function naming convention for my custom constructors (essentially replacing the generated constructor), to signify to other developers that this is the standard mock to use.
What I tried so far:
Create the mocks for which I want to use my own custom generator with --prefix=Base as to be able to use the NewMock**** function naming convention for my custom constructors
This works, but now all types related to the mock have Base in the name, which is somewhat confusing. Ideally I would just rename the constructor function.
Ditch the method of creating my own constructors and instead write them into an interface and use NewMock****From.
This works, but is far more verbose, especially when I only want to assign a default hook to one or two functions on an interface defining 20+ functions. It also requires the user of the mocks to specifically call it using the from-function and pass in the interface manually, each time, without being able to simply rely on the NewMock**** convention and get the mock with the sensible defaults.
Any suggestions on how to do this better?
Thanks again for the amazing module.
The text was updated successfully, but these errors were encountered:
First off, this module is absolutely sublime. Wonderfully convenient for developers to use. Absolutely stellar job creating the developer-facing API! This should be the number one mocking module for Gophers!
The only shortcoming I experience is as follows:
My common workflow with this module, is to generate a bunch of mocks from my interfaces, and then, for some, but not all of the mocks, create a custom wrapper function that first calls the generated constructor function, then assigns a bunch of default returns or default hooks, and return the result. This allows for a super simple way of getting a mock with sensible defaults inside of a unit test (and optionally further change some of the hooks to simulate the scenario that you want to test).
I'd like to keep these custom constructors in the same package as the mock objects, and then apply the
NewMock****
function naming convention for my custom constructors (essentially replacing the generated constructor), to signify to other developers that this is the standard mock to use.What I tried so far:
--prefix=Base
as to be able to use theNewMock****
function naming convention for my custom constructorsBase
in the name, which is somewhat confusing. Ideally I would just rename the constructor function.NewMock****From
.NewMock****
convention and get the mock with the sensible defaults.Any suggestions on how to do this better?
Thanks again for the amazing module.
The text was updated successfully, but these errors were encountered: