[Testing] InternalCommands // Injecting stubs

[Lobosque]

Hi,

What would be the recommended approach to

1. Injecting a stub to replace the default implementation of a service. My concrete use case is a Mixpanel service that connects to the outside world.

2. How do you test InternalCommands? (your System Under Test inherits from InternalCommandBase).

I understand and appreciate the fact that the module can only be accessed though its facade that allows ExecuteCommandAsync ExecuteQueryAsync. But I wonder what can be done to enable a more whitebox approach for testing, that would allow to see and manipule what's inside the module.

[Lobosque]

My current strategy is to change the I{ModuleName}Startup interface to

public static void Initialize(...)
public static void ReplaceModule(...)
public static void Build(...)

So that you can change a module (example: email) with one that registers mocks when testing.

Would love some criticism and also other alternatives to solve this.

Still not quite sure how to test InternalCommands other than seeding the database with an InboxMessage that will eventually trigger it.

[kgrzybek]

Hi @Lobosque

First of all - I moved your issue to the discussion - I hope you don't mind.

1. If I need mock/stub a dependency I pass it as an argument in Initialize method of the module. If I pass null it means a module needs to configure it itself with real implementation. I think your approach is ok too.

2. If I want to test my SomeInternalCommand processing I just make it public. Yes, this is a trade-off and "encapsulation vs testability" design concern, but in my opinion, it is worth doing that. In other words, I think an automated test is more important than a little bit exposed contract of the module.