My team has been asked to put together a Automated testing routine and standards around the same for IIB V10.

In a nutshell, our client wants us to be able to run sets of tests for both testing new functionality and  regression testing. I've gone over the documentation for the Flow Exerciser and have found a nice post (below) on using a java interface for injecting test data.

https://community.ibm.com/community/user/middleware/viewdocument/using-the-flow-exerciser-in-ibm-int?CommunityKey=77544459-9fda-40da-ae0b-fc8c76f0ce18&tab=librarydocuments

I'm looking for any good posts some folks may have squirreled away for a standard approach for testing and regression testing, saving data etc. If anyone has any good blogs out there etc.  I'm sure I'm reinventing the wheel.

Thanks for any help!
Kevin

------------------------------
Kevin Kelly
DXC
Newark DE
------------------------------

Hi Kevin
Is your DXC related with Luxoft?
Sometimes reinventing the wheel is the best recipe for innovation.
I think one needs to distinguish between testing inside the broker toolkit and testing outside the engineering environment.
Have not seen any useful public documentation yet.
I would focus on regression testing outside the toolkit where the deployment of a bar file triggers the regression and new feature testing.

------------------------------
Matthias Jungbauer
------------------------------

We use the Spring Test Framework to write integration tests.

Then you can use Spring JmsTemplate to interface with MQ queues, use Spring RestTemplate to send messages to HttpInput node, use Java JAX-WS to send SOAP message, etc.

If have have synchronous dependencies in your flow (like SOAPRequest, RESTRequest, EmailOutput), you can use widely available mocks in your JUnit tests (MockWebServer, MockEmailServer, ...). In the flows we hard code the localhost URL, e.g. http://localhost:6800 for an HTTPRequest node. This is the port, where our MockWebServer listens on in the JUnit test. The real URL for production or other non-JUnit test environments we configure in overrides.

If have FileInput/FileOutput nodes, we always define them relative und have the

MQSI_FILENODES_ROOT_DIRECTORY set in the broker. The same environment variable is available in the JUnit tests. So we know from where to read, to where to write the files. With the Sprint RetryTemplate you can for example wait until the FileOutput node has written the file before you start with your assertions.

If you need to do Broker things (e.g. stop/start flows, on/off flow monitoring), you can use the Broker java API.

If you need to do MQ things (e.g. decrease Max Queue Depth to simulate Queue Full scenarios), you can use PCF messages to manipulate queues.

Since it is all Java based, you can stay inside the IBM Toolkit to write and execute your tests.

Bottomline: We also did not reinvent the wheel, we used well known frameworks/libraries/APIs and glued it all together, like integration software developers are used to do anyway :-)

------------------------------
Daniel Steinmann
------------------------------

Original Message:
Sent: Fri January 29, 2021 05:48 AM
From: Matthias Jungbauer
Subject: V10 Automated Testing and Flow Exerciser

Hi Kevin
Is your DXC related with Luxoft?
Sometimes reinventing the wheel is the best recipe for innovation.
I think one needs to distinguish between testing inside the broker toolkit and testing outside the engineering environment.
Have not seen any useful public documentation yet.
I would focus on regression testing outside the toolkit where the deployment of a bar file triggers the regression and new feature testing.

------------------------------
Matthias Jungbauer
------------------------------

Thanks Daniel. Some great information here and some good insight. I think everyone here has their own approach and we've always been too busy to come up with a common repeatable, predictable approach. 

Thanks again,
Kevin

Thanks Matthias. 

No I am not on the Luxoft account.  The flow exerciser itself looks pretty simplistic. I think my client is really after being able to regression test. I just need to figure out the best approach where it will benefit our team and not hamper our development.  

Thanks for the new insight on testing outside the toolkit.

Kevin

Along with the good ideas others have mentioned, it's worth taking a look at a demo v11-based pipeline in ot4i at https://github.com/ot4i/ace-demo-pipeline to see one possible way to use the APIs. It's using the v11 REST APIs to record and inject messages, but those REST APIs have equivalents in the v10 Java interface, and the approach could be very similar.

The repo is aimed at pipeline use cases rather than solely testing, but modern pipelines assume testing at each stage so there's quite a lot of emphasis on testing building blocks, whole flows, etc. The application being tested is just an example, of course, and some aspects of pipelines (and integration in general) are always going to be custom for each situation, but hopefully it might spark some ideas.

Within that repo, https://github.com/ot4i/ace-demo-pipeline/blob/master/demo-infrastructure/src/com/ibm/ot4i/ace/pipeline/demo/infrastructure/RecordOneFlow.java (recording data to files) and the Java code in https://github.com/ot4i/ace-demo-pipeline/tree/master/TeaTests/src/com/ibm/ot4i/ace/pipeline/demo/tea (injecting and verifying messages) would probably be the most useful, though the example Jenkins pipeline might also be interesting. The TravisCI integration (for validating PRs, etc) is also worth a look, as it's quite possible to validate changes to ACE artifacts in a couple of minutes by using containers and Travis.

There's also some interest within ACE development in improving this whole area, so hopefully we'll have some thoughts to share at some point on how the testing picture will get better.

Great stuff Trevor! Thank you so much!!