Proposed technique for mocking standalone functions from go-fastly

[kpfleming]

THIS PR IS FOR DISCUSSION ONLY, IT IS NOT A COMPLETE IMPLEMENTATION.

Change summary

This demonstrates a possible technique for mocking 'new style' API functions in go-fastly that are not methods on the Client object. The techique requires a few things:

1. an exported "hook" variable in the command module which contains a
   function pointer which will be invoked by the command; this variable's
   default value is the function in go-fastly which would normally be
   invoked.

2. a 'MockFactory' function which returns a lambda function that mocks
   the behavior of the go-fastly function, and also asserts that the
   "input" structure passed to the function contains the parameters which
   were supplied as arguments in the test scenario.

3. a new flavor of CLIScenario (and its corresponding runner function)
   which supports the behavior above, replacing the value of the "hook"
   variable at the appropriate time and then restoring it when the test
   scenario has concluded.

4. an argument to the scenario runner which provides the address of
   the "hook" variable.

There is a lot of code duplication between RunCLIScenario and
RunAPIHookCLIScenario; that duplication can be addressed as a
follow-up project.

[kpfleming]

Creation of the 'mock' function when needed, and storage of the existing function from the hook variable.

[kpfleming]

Restoration of the original function to the hook variable.

[kpfleming]

This matches the signature of the Create function from the computeacls package in go-fastly.

[kpfleming]

The generic type parameter is needed here so that the type of theMockFactory field can be based on the signature of the go-fastly API function that is being mocked. This also provides that type information for RunAPIHookCLIScenarios to use in its hook parameter.

[kpfleming]

The new field (compared to CLIScenario) in this structure.

[jsocol]

To avoid this global, is there a way to make the CreateCommand take an APIFunc as a dependency? Like if you had something like

type CreateCommand struct {
	argparser.Base
	argparser.JSONOutput

	name string
	createFunc APIFunc
}

func NewCreateCommand(parent argparser.Registerer, g *global.Data) *CreateCommand {
	c := CreateCommand{
		Base: argparser.Base{
			Globals: g,
		},
		createFunc: computeacls.Create,
	}
	// ...
}

Or even making CreateCommand.CreateFunc public. Then you're using a form of dependency injection where the tests don't have to modify global state, and each test can have its own implementation of computeacls.Create that returns whatever it needs

[kpfleming]

The object returned by NewCreateCommand is not accessible to the tests, it's stored inside Kingpin (the command-line parser we use). The interface from the tests into that is supplying a string which represents an array of command-line arguments which are then parsed and handled as if a user had typed them. It's really not a unit test, even though that's how we think of it.

[anthony-gomez-fastly]

i run into this all the time when trying to genericize inputs for similar function groups, it's a real pain