MassTransit/MassTransit — Issue #75: Transports Specs
Author: haf
Created: 2012-02-01 09:00:33+00:00
State: open

**Suggestion that would make it easier to implement and manage transports**

I think we could create a common test project that pulls in all transports and test them. By running the tests in this project as a part of a 'certification workflow' we could ensure different levels of transport compliance. The reason I'm suggesting a test suite rather than a written specification is that it would probably be easier to get the test suite harvested from existing code than to write anew.

The test suite would be responsible for testing all the failure conditions, such as serialization problems, oversized messages, transports that go down with exceptions. The failure conditions could be wowen into the transports either with a runtime such as Moles or by adding instrumentation to the code itself.

The test suite would be responsible for testing all positive conditions, such as concurrent/interleaved consumption, pub-sub ordinarily, polymorphically/interfaces, multiple-interfaces, selective handlers/consumers/peeking, routing between in-proc buses, sending to specific endpoints, static routing etc.

By doing this, we could group the test fixtures themselves by the levels that the transport aims to support and let programmers worry about implementing a very fixed set of specs rather than trying to reverse-engineer existing transports.

We could begin by harvesting everything from MSMQ and RMQ, and then use that to test AzureServiceBus/Stomp transports and the move on to ZMQ transport.

It would aim to bring down the overhead for creating these transports while making it better documented (through e.g. comments and literate test specification in the transport certification project).