Testing endpointconfiguration

1

Hello,

Do you have advice on testing endpointconfiguration? I now use (hidden) magic strings to test it.
We use sqlserver transport.
Some parts are important in the behavior f.ex. transactionscopemode, audit etc.
I would like ensure that with tests.

See my example.
(Side note, because endpointconfiguration takes up quite some lines, we use builders for setting it up, therefor in the arrange is custom code from us)

    [TestClass]
public class TestEndpointConfiguration
{

    [TestMethod]
    public void TestSendOnlyConfiguration()
    {
        // ARRANGE
        var endpointConfigurationBuilder = new SqlEndpointConfigurationBuilder(endpointName: "MyQueueName", connectionStringOrName: "MyDbName", schemaName: SqlEndpointConfigurationBuilder.SqlSchemaNameDefault);
        endpointConfigurationBuilder.WithAutofacContainer(MyDIContainer);
        endpointConfigurationBuilder.AsSendOnly();

        // ACT
        var endpointConfiguration = endpointConfigurationBuilder.Build();

        // ASSERT
        var configuredSettings = endpointConfiguration.GetSettings();

        Assert.AreEqual("MyQueueName" configuredSettings.Get("NServiceBus.Routing.EndpointName"));
        Assert.AreEqual(true, configuredSettings.Get("Endpoint.SendOnly"));
        Assert.AreEqual(SqlEndpointConfigurationBuilder.SqlSchemaNameDefault, configuredSettings.Get("SqlServer.SchemaName"));
    }

    [TestMethod]
    public void TestReceiveConfiguration()
    {
        // ARRANGE
        var endpointConfigurationBuilder = new SqlEndpointConfigurationBuilder("MyQueueName", "MyDbName", SqlEndpointConfigurationBuilder.SqlSchemaNameDefault);
        endpointConfigurationBuilder.WithDefaultAuditQueue();
        endpointConfigurationBuilder.WithAutofacContainer(MyDIContainer);
        if (OnError != null) endpointConfigurationBuilder.WithCustomRecoverability(settings => settings.Failed(x => x.OnMessageSentToErrorQueue(OnError)), preserveDefaults: true);
        if (OnCriticalError != null) endpointConfigurationBuilder.WithCriticalErrorAction(OnCriticalError);
        endpointConfigurationBuilder.WithDiagnosticsPath("SomePath");

        // ACT
        var endpointConfiguration = endpointConfigurationBuilder.Build();

        // ASSERT
        var configuredSettings = endpointConfiguration.GetSettings();

        Assert.AreEqual(Queues.Node, configuredSettings.Get("NServiceBus.Routing.EndpointName"));
        Assert.AreEqual(false, configuredSettings.Get("Endpoint.SendOnly"));
        Assert.AreEqual(SqlEndpointConfigurationBuilder.SqlSchemaNameDefault, configuredSettings.Get("SqlServer.SchemaName"));
        Assert.AreEqual("MyQueueName.Error", configuredSettings.Get("errorQueue"));
        string auditAddress;
        NServiceBus.AuditConfigReader.TryGetAuditQueueAddress(configuredSettings, out auditAddress);
        Assert.AreEqual("Audit", auditAddress);
        Assert.AreEqual(TransportTransactionMode.TransactionScope, configuredSettings.Get("NServiceBus.TransportTransactionMode"));
    }

    Func<FailedMessage, Task> OnError;
    Func<ICriticalErrorContext, Task> OnCriticalError;
}
2

Hi Neum

Have you thought about making this some kind of an approval test instead? For example starting a regular endpoint with the configuration you want and then approve the feature startup diagnostic file from disk.

It seems with the current approach you are basically testing internals of NServiceBus that we already take care of and if I understood you correctly your intent is to verify that the “production” settings are correctly applied. All the relevant production settings will be available in the diagnostics that’s why I’m suggestion this alternate route.

Regards
Daniel

3

Hello Daniel,

Yes my intention is to verify that a certain configuration was set and not changed without changing the tests.
If i understand correctly, the suggestion is to verify the contents of the diagnostics file.
Testing the contents of this file, means i still would have to resort to magic strings. I consider that isn’t better or worser than how i test it now. (testing a 1-on-1 copy of the file is not ideal either i think, because of some changes on infrastructure, f.ex. the host(=a build server in a pool, which can change with a next build)
Not having to run the instance has it advantages of being more unit testable. As you said, i don’t need to test what was already tested by NServiceBus. I only want to verify that the developer did apply some settings.

Regards Nikias

4

Hi

The way how approval tests handle that is by having an ability to scrub data that is not relevant or constantly changing. An example of that is also available in the excellent Verify lib of Simon

Regards
Daniel

5

I actually have explicit support for verification of NSB stuff here GitHub - VerifyTests/Verify.NServiceBus: Adds Verify (https://github.com/VerifyTests/Verify) support to verify NServiceBus Test Contexts

happy to add verification of NSB config if someone wants to use it

1 Like