Traffic Parrot supports GCP Dialogflow gRPC mocks

When working with complex cloud services such as GCP Dialogflow, it can be useful to use API mocks to test different hypothetical integration scenarios, without the need for a real GCP service to be configured and available.

We have a sample project available which you can use with a free Traffic Parrot trial to mock bidirectional streaming Dialogflow services, without the need for a live GCP instance.

Traffic Parrot 5.34.3 released, what's new?

We have just released version 5.34.3. Here is a list of the changes that came with the release:

Features

• Added example of GCP Dialogflow gRPC bidirectional streaming mocks

Fixes

• Library upgrades to fix OWASP issues

How do I forward the HTTP requests I don't have mappings for to another endpoint?

Sometimes we need to work with a mixture of real and mock APIs, for example using mocks for APIs that are not yet developed and real APIs for those that already exist.

To support this use case, you can use Traffic Parrot to forward HTTP requests to another endpoint instead of returning the default "not found" response.

You can use the proxy responses feature to provide a default response for unmatched requests:

1. Set a low priority like 10 for the mapping with the proxy response
2. Leave default priority for other non-proxy response mappings
3. Now any unmatched requests will return a response from the proxy mapping

How pair-programming brings down knowledge silos

One of the proven ways of eliminating knowledge silos is pair-programming (or pair-testing for QAs). A team of researchers from Pivotal has concluded that a flavour of pair programming with overlapping pair rotation described in “Sustainable Software Development through Overlapping Pair Rotation“ “encompasses principles, policies, and practices aiming at removing knowledge silos and improving code quality (including discover-ability and readability), hence leading to development sustainability.”

They note that “Conventional wisdom says that team disruptions should be avoided, and that extensive documentation is needed to prevent knowledge loss during team churn. Unfortunately, documentation often quickly becomes out-of-date and unreliable. The theory positions team code ownership with overlapping pair rotation and knowledge pollination as an alternative and potentially more effective strategy to mitigate against knowledge loss”.

From our experience gathered with Traffic Parrot customers, we can confirm these findings and that pair programming can be used as an effective way to eliminate knowledge silos and prevent critical knowledge loss. We have seen pairing developers with testers work equally well at sharing knowledge and helping bring down silos between QA and Development.