TDD and Neuron

Replies to This Discussion

Permalink Reply by CM on June 24, 2009 at 12:59pm

This is challenging when working with any advanced intermediary because in order to do this thoroughly you really need a running instance of the server and by the nature of the product nearly infinite paths are possible. Mocking is much more impractical with buses than with things that are intended to do a "thing".

For components hosted in code shapes you can absolutley develop those tdd.

For scenarios via pub sub where there can be N subscribers I'm not sure the ideas blend all that easily. You can test that your messages are sent correcty for your current patterns/topology and then you can check the expected state of endpoints. Even using this method there is typically a challenge to "How many times do you check?"..I remember doing this with another platform and had to considerably alter my expectations and success conditions because the process would take longer than expected when any load was applied and that load varied not only by number of message in a time span but message size.

The method of focusing on the inputs and outputs for your use case and treating the middle like something that can be altered without your knowledge may not make a TDD purist happy but in the end in my opinion will actually give you a realistic view of the process that will actually occur.

For automating deployments, overrides etc powershell is pretty good but you can use any technology you'd like that essentially simply launches enternal processes ..even the lowly bat file...

• ▶ Reply

Permalink Reply by Frosty on June 24, 2009 at 3:25pm

Challenging is a good adjective to describe this task, but that also adds to the enjoyment in solving the problem. Maybe narrowing down the scope is help to make this more manageable.

In our environment, as I am sure we have discussed before, but for the benefit of others, we are mostly focusing on an Event Driven Architecture (EDA). This is not to say that using a request / response pattern is not allowed, but we think that we can gain significant mileage / productivity / integration by focusing on EDA.

Going the EDA route also simplifies our developer experience and draws clear lines of responsibility for the publisher, ESB, and subscriber touch points.

Publisher: Send a message to the ESB that conforms to an agreed upon contract / schema

ESB: Deliver said message (transforming, if necessary to an agreed upon contract / schema) to all subscribers , without fail (i.e. guaranteed delivery)

Subscriber: Receive said conforming message, and do with it as sees fit.

There are of course other caveats and courses of action, but for the most part, it is as simple as stated above, without taking us completely off topic.

So … to apply Test Driven Development principals in this environment there are a couple of distinct testing areas. One, as mentioned, is in validating pipeline steps and entire pipelines: Expected input goes in; Evaluate output to expected output. Since the pipelines are developed outside of Visual Studio, how does one set up a repeatable testing process? The test button in the pipeline designer makes an attempt at this, and I suppose is usable for quick tests during development, but I am looking for a more automated way of testing. I am a big fan of Powershell, but still not quite sure how this would fit into a testing scenario. How can one indepentently test a single pipeline step? Your thoughts / examples greatly appreciated here!

The other major area of testing would be to test the pub / sub routing and delivery of messages. Again, given our environment: Expected input goes in; Expected output shows up (or not). To exercise this area, I can envision how endpoints can either be mocked / simulated or that pipelines could be used to record destination and message state to either a database or file system. Where I am having trouble, is how to do this using actual ESB artifacts. If I were doing this in say VS, I could enable tracing or some other diagnostic feature via a configuration file or compiler switch. Is it possible to do something similar in Neuron? Do Environment Variables come into play to accomplish this?

I can see where the 2.1 version of Neuron and more specifically the new Pipeline Designer really expands the possibilities to do TDD, but still waiting for that “Ah Ha” moment to occur.

• ▶ Reply