test dbos mocks

[maxdml]

• Add a test exercising the mocking of the DBOSContext and WorkflowHandle interfaces
• We need a wrapper handle for the mock Path in RunWorkflow (it does return a new handle from the DBOSContext.RunWorkflow). This will only be used on the mocking path.

[maxdml]

The only importers of this module are our tests and they should always get the mocks from the development directory.

[kraftp]

What does this do? It looks sketchy.

[kraftp]

I see, the mocks files are being committed as part of our core codebase--do we really need to do that?

[kraftp]

What does this do? Why do we need it? Do users need to worry about it?

[maxdml]

The situation we have with RunWorkflow, is that only the interface methods are mockable. If you want to mock RunWorkflow and have it return a mock handle, only the "inner" call with get a mock. Then, in the package level method, we use information from that handle to return a new typed handle. This new handle, not being the mock, makes testing impossible.

What this does -- users don't need to worry -- is to fall back on a "proxy" handler if the interface RunWorkflow does not return the "normal" handlers (direct or polling). The proxy just calls in whatever was returned by RunWorkflow. This allow a mock handle to be passed through.

[kraftp]

Can't we just return a polling handle (passing in the mocked context) instead of this new thing?

[maxdml]

Returning a new polling handle would be returning a new object that is not the mock returned by DBOSContext.RunWorkflow. We need a way to pass through the mock while respecting the function signature (return a generic WorkflowHandle[R] interface). Unfortunately we cannot just "cast" the mock (SomeMockType[any]) to WorkflowHandle[R]: any and R are different type. This proxy type:

• Let us pass through the mock
• Let us returned a typed mock