Solving QA Environment Availability Issues with Partial Pass-Through JMS IBM MQ Mocks

Testing teams often face common QA environment challenges:

• Environment downtime
• Intermittent errors from backend systems
• Test data setup takes weeks
• Teams conflict over shared test data
• Limited test scenarios

While the long-term solution involves stabilizing shared environments and implementing testing pyramids, here's a quick fix using Traffic Parrot's partial pass-through mocking capabilities.

We implemented this solution for a mobile onboarding application connecting to IBM MQ middleware. By creating mock queues alongside production queues, we enabled:

• Simultaneous mocked and real responses based on test data
• Automated test data setup and reset
• Extended test coverage for previously unavailable scenarios
• Reduced environment dependencies

 Key Implementation Steps:

• Create additional mock queues
• Reconfigure client to use mock queues
• Set up pass-through mocks in Traffic Parrot

The beauty of this approach? You maintain real system integration while having the flexibility to mock specific scenarios. For example, we successfully mocked unsupported mobile service types while passing through all other requests to the actual backend.

Want to try it yourself? Check out Traffic Parrot's demo applications on GitHub, which have step-by-step implementation guides.

Partial passthrough and proxy HTTP mocks

Are you struggling with unstable QA environments, conflicting test data, or time-consuming setups?

Meet partial HTTP mocks using Traffic Parrot.

Here's how it works: Traffic Parrot acts as a smart proxy between your app and backend systems. Regular requests go to the real system, while special test cases use predefined mock data.

In our demo, a financial app gets real stock prices for Apple and Google but uses mock data for test scenarios like unlisted companies.

The result? Always available environments, stable responses, and quick test data setup - all without changing your core systems.

Using Handlebars for Date Comparisons in Response Logic in Traffic Parrot

 We received a question recently from one of our prospects.

"I wanted to know about the advanced usage of dynamic rules. How do I add scripting for my response logic? I need some date comparisons for calculating some fields values, is it possible to with scripting or handlebars?" - Software Developer working for a gaming company.

You can add scripting to your response login with scripts or handlebars. Here is the documentation on how to do that: https://trafficparrot.com/documentation/5.50.x/dynamic.html  

Handbars should be enough for this simple case of comparing dates.

For example, you can add this into your response body like on the screenshot displayed below:

{{#if (gt (date (parseDate request.query.SomeDate format='dd-MM-yyyy')) (date (now)))}}
Response if the defined date is after now
{{else}}
Response if the defined date is not after now
{{/if}}

This code compares SomeDate request query parameter with today's date and returns a different response based on that comparison. 

Here is an example result:

support@support-pcs:/optf/git$ curl http://localhost:8081/hello?SomeDate=01-01-2024
Response if the defined date is not after now
support@support-pcs:/optf/git$ curl http://localhost:8081/hello?SomeDate=01-01-2025
Response if the defined date is after now

How to configure Traffic Parrot log level at runtime in Docker

We got a question from one of our customers about how to configure the log level at runtime when using Traffic Parrot in Docker.

How to pass environment variables to Docker

The Dockerfile CMD command can be modified to accept environment variables as follows:

ENV GUI_HTTP_PORT=8080
ENV VS_HTTP_PORT=8081
CMD exec ./start-foreground.sh \
    trafficparrot.gui.http.port=$GUI_HTTP_PORT \
    trafficparrot.virtualservice.http.port=$VS_HTTP_PORT

How to set the logging level dynamically with Docker environment variables

First the Dockerfile can be configured with an environment variable:

ENV LOG_LEVEL=ERROR

This can be then be configured for use:

• trafficparrotserver.log4j.properties can be configured with:

  log4j.rootLogger=${LOG_LEVEL},file,stdout

  And the Dockerfile with:

  CMD exec ./start-foreground.sh -DLOG_LEVEL=$LOG_LEVEL

• trafficparrotserver.log4j2.xml can be configured with:

  <Root level="${env:LOG_LEVEL}">

• trafficparrotserver.logback.xml can be configured with:

  <root level="${LOG_LEVEL}">