Neuron ESB User Network

The Service Bus for the Connected Business

Does anyone have any thoughts on using TDD (Test Driven Development) via the ESB? Specifically in validating pipelines and performing transformations for web service connectors? General pub / sub routing?

Views: 190

Reply to This

Replies to This Discussion

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...
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.

RSS

Neuron ESB Product Support Forums and Communities

Latest Activity

Profile IconRobert E Dunie and Sayantini Basak joined Neuron ESB User Network
Apr 28
Profile IconDayanand, Frederic C, Steffen Greve-Oksfeldt and 1 more joined Neuron ESB User Network
Mar 16
Profile IconCam Vong and Mitja Luznar joined Neuron ESB User Network
Jan 27
Profile IconWill Hitzges, Chad Parsons, michael larsen and 4 more joined Neuron ESB User Network
Jun 11, 2021
Anupama Nair posted a discussion

ODBC stored proc polling with temporary tables

We have set up an ODBC adapter to poll a stored proc.We found that if the stored proc has a temporary table defined the rows returned are always 0.Any idea why this would be and what we can do to get around it?See More
Dec 14, 2020
Prasanth Kharade is now a member of Neuron ESB User Network
Dec 30, 2019
Suman vadde is now a member of Neuron ESB User Network
Dec 16, 2019
Morten Andreasen is now a member of Neuron ESB User Network
Dec 9, 2019

Badge

Loading…

© 2022   Created by Neuron Admin.   Powered by

Badges  |  Report an Issue  |  Terms of Service