Add default headers to TestableMessageHandlerContext

[tmasternak]

Usage of TestableMessageHandlerContext would be easier (fewer lines of code to setup) if it would provide default header values for commonly used headers eg ConversationId and TimeSent etc

[DavidBoike]

@SimonCropp can you give me any more detail about what you're looking for here? Are we talking about "emulating" NServiceBus so that when testing MessageA, that the result is that MessageB is sent/published with specific headers in relation to MessageA?

That might work for some things like CorrelationId / ConversationId, but I'm concerned that for anything like TimeSent we'd require some form of time provider to be in play.

Or are you looking for a method that would pre-fill the headers in the testable context (related to the incoming message) with some default valid-looking values?

Or something else?

I'm also struggling with how to provide anything like this in an opt-in format that wouldn't break a bunch of existing tests.

We're already planning a minor release of the testing framework, so I'd love to figure out if this could ride along.

[SimonCropp]

many extension points to NSB make assumption about the existence of certain headers.

For example we have an email endpoint that we attach nsb headers for debugging purposes

        mailHeaders.Add("ConversationId", messageHeaders[Headers.ConversationId]);
        mailHeaders.Add("CorrelationId", messageHeaders[Headers.CorrelationId]);
        mailHeaders.Add("MessageId", messageHeaders[Headers.MessageId]);
        mailHeaders.Add("OriginatingEndpoint", messageHeaders[Headers.OriginatingEndpoint]);

If the nsb test lib populated these with some hard coded (but different) guids. i would save use having to set these in tests. hard coded guids means tests that assert on these values could continue to work. note asserts on known guids would not effect us since we use guid scrubbing/replacement

anything like TimeSent we'd require some form of time provider to be in play.

I think TimeSent could be DateTime.now. can sill override their own value, and use a time provider if they want

opt-in format that wouldn't break a bunch of existing tests

perhaps a api to enable it that people can call in a module initializer

[SimonCropp]

Note this is the same as the approach you already use for MessageId and ReplyToAddress

        /// <summary>
        /// The Id of the currently processed message.
        /// </summary>
        public string MessageId { get; set; } = Guid.NewGuid().ToString();

        /// <summary>
        /// The address of the endpoint that sent the current message being handled.
        /// </summary>
        public string ReplyToAddress { get; set; } = "reply address";

although i would prefer MessageId to be hard coded