Mediatr: Question: What the best way architectural pattern to structure handlers to allow unit testing of business logic

Created on 8 Aug 2016  Â·  6Comments  Â·  Source: jbogard/MediatR

We used MediatR in a couple of simple apps with EF. We are about to embark on a much bigger more complex app and it's not using EF.

Back in the day we would mock out the repository to allow us to test our business logic, we've got back control of our data access now using MediaR but we side-stepped the unit test question by using effort previously.

How have others have structured their MediatR request handlers to allow them to unit test their business logic ?

Should we consider the handler a replacement of the repository pattern and therefore place business logic outside of the handler ?

Most helpful comment

If you want to unit test business logic push the business logic into your
domain objects. Integration test MediatR handlers, unit testing them is
probably a waste.

On Monday, August 8, 2016, John Kattenhorn [email protected] wrote:

We used MediatR in a couple of simple apps with EF. We are about to embark
on a much bigger more complex app and it's not using EF.

Back in the day we would mock out the repository to allow us to test our
business logic, we've got back control of our data access now using MediaR
but we side-stepped the unit test question by using effort previously.

How have others have structured their MediatR request handlers to allow
them to unit test their business logic ?

Should we consider the handler a replacement of the repository pattern and
therefore place business logic outside of the handler ?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/92, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMjnRcO-QOP_bwNhhgKC48sPGYkQCks5qdyhDgaJpZM4JfBGM
.

All 6 comments

If you want to unit test business logic push the business logic into your
domain objects. Integration test MediatR handlers, unit testing them is
probably a waste.

On Monday, August 8, 2016, John Kattenhorn [email protected] wrote:

We used MediatR in a couple of simple apps with EF. We are about to embark
on a much bigger more complex app and it's not using EF.

Back in the day we would mock out the repository to allow us to test our
business logic, we've got back control of our data access now using MediaR
but we side-stepped the unit test question by using effort previously.

How have others have structured their MediatR request handlers to allow
them to unit test their business logic ?

Should we consider the handler a replacement of the repository pattern and
therefore place business logic outside of the handler ?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/92, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMjnRcO-QOP_bwNhhgKC48sPGYkQCks5qdyhDgaJpZM4JfBGM
.

Hey @jbogard, thanks for the response.

I see how that this might work for CRUD operations but say I have a request handler that is doing a complex employee balancing calculation which returns a result that is passed into other handlers how should I test this ?

It doesn't belong to any single domain object as it uses a bunch of domain objects together to come to an answer.

I was to do as you suggest I'd add end with a pretty slow integration test would I not, If I got it right I'd have to create and seed a real database, run the tests against the handler and then I'd I guess I clean down the database or re-set it's state.

Or am I missing something / change my way of thinking ?

It sounds like you are talking about a saga. I was wondering how to implement this myself.

Create a service then, and delegate to that. Once inside your handler, the normal DDD rules can apply. Push behavior down to domain objects, create services to coordinate between entities.

I just don't create repositories _solely_ to unit test. Instead I push behavior down to services that don't take those dependencies in the first place.

Services - ok I see, so anything which needs to span multiple objects has a coordinating service which is easily unit tested as I can mock out the dependant objects.

Back to your integration test point, I sort of like it as nothing beat a real end to end test but I have questions:

1) We use a lot of MS Azure Services (for example documentDb) which don't have local emulators (they are coming apparently), this means that local testing for our devs is challenging and we will end up coming up with some kind of setup test which passes in their own connection details + their is CI to consider. In the bad old repository days we would mock out the repo and run it all from memory.

2) Integration Setup and Clean Up - I'm worried about the time and structure of the tests to balance the need for clean state for each test vs. time taken to setup and clean up the test artifacts.

Do you have a pattern you follow ? What do your test projects look like ?

For example do you have a test assembly per domain object with say setup of dependent state for the tests inside the setup method and the clear down ?

Sorry for all the questions, just trying to drain your brain before I get going with the new project :-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tool-cmd picture tool-cmd  Â·  4Comments

zachpainter77 picture zachpainter77  Â·  5Comments

mdmoura picture mdmoura  Â·  4Comments

grokky1 picture grokky1  Â·  4Comments

FuncLun picture FuncLun  Â·  5Comments