Closed arowse-pfl closed 5 years ago
Hmm... you are absolutely right, there is no good way to have the ResolveConflict
method called in a deterministic fashion.
It would actually be pretty nice if it was possible somehow. I could imagine something centered around SagaFixture
from Rebus.TestHelpers, but I don't know what it should look like.
Let me think about it 😄
Rebus.TestHelpers now has the ability to set up saga data update conflicts in a controlled fashion.
You can do it like this:
using (var fixture = SagaFixture.For(() => new ConflictSagaHandler()))
{
// deliver a message, causing the saga data to be created
fixture.Deliver(new SomeMessage("some-id", "HEJ MED DIG"));
// mark the saga data to cause a conflict on the next update
fixture.PrepareConflict<ConflictSagaHandlerData>(d => d.CorrelationId == "some-id");
// this update will experience a conflict
fixture.Deliver(new SomeMessage("some-id", "MIN VEN"));
}
It's available on NuGet.org in Rebus.TestHelpers 5.2.0
Thanks for suggesting this feature 😄
Awesome! I'll check it out and add it to our unit tests. Thanks Mog
There appears to be no good way to write a unit test that covers the ResolveConflict method on the Saga class.
There doesn't appear to be any support in the Fake* classes to force a conflicted state and force the ResolveConflict method to fire. Additionally, that base class method is marked as protected so directly calling it is not very feasible.
Is there something that can be added in order to aid getting unit test coverage for ResolveConflict method implementation?