Mock transport

[whittle]

I’m familiar with #133, and the fact that a free monad was implemented and then removed in #186. I have been able to get most of what I need by replacing Control.Monad.Trans.AWS.send throughout my application with a wrapper that uses Control.Monad.Trans.AWS.send as its default implementation, but during testing can be swapped with a mock that casts the request to an appropriate type at runtime and either fails the test or returns a fixed response as appropriate.

This works fine, just so long as my application is the only place from which Control.Monad.Trans.AWS.send is called. I’m trying to use amazonka-s3-streaming now, which breaks that assumption.

I suspect what would simplify thing greatly for me—and for anyone else attempting to mock their app’s AWS interactions—would be to create a class AWSTransport with members send and await, and then have either AWS or AWST' implement that class with the existing implementations of send and await, and make MonadAWS dependent on the AWSTransport class.

Is something like that within the realm of possibility?

[axman6]

Hey @whittle, I'm the author of mzonka-s3-streaming (which should be renamed so it doesn't look like an official package, but I don't have a good name for it). Is there anything that could/should be changed in s3-streaming to help?

[whittle]

Hi @axman6, thanks for amazonka-s3-streaming. I’m trying to get more comfortable using conduits, and having your library really helps.

All I can think of that your library would do would be to implement the same sort of thing, but library-specific. So, you would have something like

class AWSConstraint r m => S3Streaming m where
  send :: AWSRequest a => a -> m (Rs a)
  await :: AWSRequest a => Wait a -> a -> m Accept

and then provide an instance of S3Streaming for either AWS or AWST' that uses the existing implementations of send and await. Then, for my application-specific transformer stack, I’m free to implement S3Streaming for it in such a way that I can swap out a mock implementation for the real one at test run-time.

[endgame]

This would be nice to have eventually, and @brendanhay has mentioned that he wants to deprecate and remove the MTL-style code (not sure if it will actually happen; see #652 which is a summary of #617). But it's not material for the 2.0 RC.

[endgame]

I don't think it makes sense to have this open any more - amazonka 2.0 dropped the MTL-style constraints, which should make it significantly easier to mock via one's mechanism of choice.

If I'm wrong on this point, please sing out. We can reopen and discuss.

[endgame]

I suspect that what libraries like amazonka-s3-streaming would want to do is parameterise themselves over a function AWSRequest a => a -> m (AWSResponse a) (either directly, or through an effect system or whatever makes sense). @axman6 does this make sense to you?