Mock utility for command call tests

[crossplane]

Mock utility for command call tests

[sergenyalcin]

Before starting implementation, I want to write a proposal here to discuss the architecture of this utility.

We have a CommandContext function that returns a *Cmd object. Then, this object is used for calling the CombinedOutput function. It runs the cli command and gets the output. Here we need interfaces to implement the different behaviors, real and mock.

First interface is Exec. It has CommandContext function that returns another interface Command:

type Exec interface {
	CommandContext(ctx context.Context) Command
}

The main purpose of this interface is to determine the struct to be used in the GetCombinedOutput function (Real or Mock). There will be two structs that implement the CommandContext function of Exec interface:

type RealExec struct
type MockExec struct

Second interface is Command. It has GetCombinedOutput function.

type Command interface {
	GetCombinedOutput() ([]byte, error)
}

There will be two structs that will implement the GetCombinedOutput function of Command interface

type RealCommand struct
type MockCommand struct

The RealCommand implementation will call the exec.CombinedOutput function. Mock implementation will set the stdOut, stdErr, exitCode etc. fields of Cmd struct. By this way, without running the cli command, we can test the behavior of workspace functions.

[muvaf]

Thanks for writing this down @sergenyalcin ! I love how you decided to start with the minimal set of functions on the interfaces that can grow over time.

type RealExec struct
type RealCommand struct

Is there a way to avoid having these structs? It seems like if we make Command interface compatible with *exec.Cmd methods, i.e. naming CombinedOutput instead of GetCombinedOutput, we can achieve that. I didn't dive deep but that's probably harder for RealExec since original CommandContext returns *Cmd instead of an interface or simple type.

Another thing to keep in mind that I think we should treat this as layer between user and the underlying implementation instead of only a test utility, i.e. there could be some other implementations in the future that will use this with different back-ends like remote SSH execution. Implication of that would be for example, instead of MockCommand, we can call it CommandInMemory (or something not have to do with mocking) where it saves the env vars and the bash strings in a single object in memory where you can check against.

In fact, it could grow into its own open source project that will allow people do such things, similar to afero.

[sergenyalcin]

While working on this issue, I observed that, a utility for this aim was already implemented in k8s.io/utils:

https://github.com/kubernetes/utils/blob/master/exec/exec.go
https://github.com/kubernetes/utils/blob/master/exec/testing/fake_exec.go

It seems that, the general architecture is similar to our design and it is suitable for us. We may consider to use this utility instead of implementing the new one. So, I am closing this issue for now, In case we encounter a problem while developing the unit tests, we can continue to work on this issue again.