Due to non-mockability it is a bit tricky to setup a unit test for Azure service bus.
I have found a resource to help me: https://www.mrjamiebowman.com/software-development/dotnet/net-unit-testing-azure-service-bus/
Reading through said article while writing code solved the issue for me. And you hopefully.
In an O/RM solution the business logic often ends up in the very queries. Don’t mock them if you want to test business logic.
TL;DR
Some hundred years ago when Microsoft was pushing their first Entity framework and all examples were PresentationLayer<->DataAccessLayer someone asked “When one is using an O/RM; where is the business logic?”
After all this time I have finally found out. In the very queries.
This effects the unit tests.
Because what you often want to test with unit tests is business logic and mock out everything else. The call to the O/RM is often quite simple. Then comes some hefty Linq statement that translates to EF or nHibernate. Then follows some simple handling of the result. The main logic is in the O/RM call.
So when one mocks out the O/RM one mocks out a big part of the logic.
One solution is to not mock out the O/RM but instead mock the data retrieval beneath. I have not figured out how to do this.
Another solution is to do an integration test all the way to the database. My first try at this was messy but worked out. My second try was equally messy but also worked out and has returned the investment many times. My third, and present, try uses helper methods to set up the data and contrary to the earlier tries it doesn’t look messy any more.
This is inspired by my present gig where the QA guy wrote a simple DSL with fluent syntax to set up test data. I have not managed to replicate his library but am, presently, happy with helper methods.
I have tested and really liked ApprovalTests with more info in the blog by Llewellyn Falco.
When the unit test fails, and only if it fails, a comparer of choice pops up (think Winmerge or similar).
Say you have a long string where, somewhere, the testing framework reports a diff; you have to sift through the whole 1000 characters and compare by eye. If the discrepancy is a space/tab or apostrof/accent you might have a very hard time to spot the diff.
Or say you have an object with 10 or so properties. The unit testing framework reports a diff and you have to iterate through the properties and maybe sub properties for two objects. Tedious and not fun even the first time. The third of 10th time you really should be looking for a better solution.
I started writing my own but dropped that project in a second for AprovalTests.
Another, not as polished, solution is from SHaack. It is an extension to a unit test framework. You have to implement your own if you have another unit testing framework of choice.