Best practice for injecting dependencies in unittests

[sanderobdeijn]

We have written our unit tests to use a service collection and use the scanassemblies method to inject our fluxor classes in the service collection.

But this means that all features, effects and reducers are injected into the service collection. This means that effect that aren't in scope for the test are also injected and their dependencies need to be mocked/faked.

Is there some way to limit scanassemblies to only a specific namespace maybe?

Or is it best practice to not use a servicecollection or scanassemblies for unittests?

[mrpmorris]

Sounds more like integration testing than unit testing.

To unit test a component you'd give it mock state and a mock dispatcher.

[sanderobdeijn]

Ok sorry integration testing then.
Because we are new with fluxor we want to test our fluxor configuration.
Because of tests we now have, we already found issues in our fluxor code when upgrading from 3.9 to 4.0.
We had a class that inherited from effect but also had effectmethod attributes. Which didn't seem to cause issues in 3.9. But every action dispatch then caused an effect to be called twice.
To prevent more issues like that, we would like to wire up fluxor like it will run in production but mock the depencies on the rest of the system.

[mrpmorris]

If you create your own ServiceCollection, register your mock services, and then call AddFluxor on it, when you create an IServiceProvider from it and resolve IStore you will be able to call InitializeAsync and then dispatch actions.