Monday, 19 August 2019

Twitter @java: Testing Microservices - Overview of 12 Useful Techniques - Part 1 with Liam Williams

Thanks to @java for the recognition by Tweeting Liam's and Wojciech's article!


"The combination of a microservice architectural style and container-based infrastructure requires a testing strategy that is compatible with this brave new world. A microservice architecture relies more on over-the-wire (remote) dependencies and less on in-process components, and your testing strategy and test environments need to adapt to these changes." - Wojciech Bulaty and Liam Williams for InfoQ

Read more: https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/

Trending article: 12 useful techniques when testing microservices

Liam and Wojciech's article "Testing Microservices: Overview of 12 Useful Techniques - Part 1" is trending at position 1 on InfoQ!


"When working with microservices, you have more options because microservices are deployed typically in environments that use containers like Docker. In microservice architectures, your teams are likely to use a wider variety of testing techniques. Also, since microservices communicate more over the wire, you need to test the impact of network connections more thoroughly. Using tools and techniques that better fit the new architecture can allow for faster time to market, less cost, and less risk." - Wojciech Bulaty and Liam Williams for InfoQ.

Read more: https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/

Saturday, 17 August 2019

Traffic Parrot 5.4.0 released, whats new?

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

Features

  • Added JMS REST API to count the number of requests made that match the given criteria using POST /api/jms/requests/count and reset the count using DELETE /api/jms/requests
  • See the OpenAPI documentation or import the Postman workspace for more information on the API usage

Fixes

  • Fixed usage of {{ anyNumber }} to match numbers within JSON string fields

Friday, 16 August 2019

Testing Microservices: Overview of 12 Useful Techniques - Part 1

"The combination of a microservice architectural style and container-based infrastructure requires a testing strategy that is compatible with this brave new world. A microservice architecture relies more on over-the-wire (remote) dependencies and less on in-process components, and your testing strategy and test environments need to adapt to these changes." - Wojciech Bulaty and Liam Williams for InfoQ 15th Aug 2019.

Liam and Wojciech have just published an article about testing microservices. A big thank you to the InfoQ editorial team, who were fantastic help getting this article ready.



Sunday, 11 August 2019

How multiple teams can use Traffic Parrot

“Is it possible to segregate a Traffic Parrot installation across multiple teams?” - Consultant Developer at a global software consultancy in Portugal.

It's a great question, and we hear it quite often, so we have decided it would be good to blog about it!
Start with exploring the "3 ways to deploy and share virtual services and API mocks".

If you want to use Diagram 3 deployment style which is where we recommend using Traffic Parrot, Diagram 3a below shows an example of how you could configure TP to be used by multiple teams:


Click to enlarge
On the left, you see a team responsible for the Legacy Banking Application. They used to have two environments DEV and QA that now connect to a Payment virtual service. They also have a CI build in Jenkins, and develop the application on their laptops. All of those environments use the same versioned virtual service artifact, that is used to spin up the Payment virtual service.
On the right, you can see another team in the same organisation but working in the new world of microservices. Developers and QAs are running developing and testing those microservices on their laptops, but they also have a GitLab pipeline setup. All of those laptops and the pipeline are running separate virtual services that are built from the source code and versioned in GIT source code.

Here is a sample workflow of how you can manage your API mocks as code to handle the distributed deployment and versioning of the API mock artifacts in the example above:


Click to enlarge
You can see a sample developer workflow, how to create the API mocks (virtual services), test them together with the microservice. The workflow ends in the developer checking in and pushing his changes to GIT. And then a GitLab pipeline picking up those changes and running the checks, publishing and deploying the artifacts.
Please keep in mind, these are only examples to demonstrate how our clients use Traffic Parrot, the details can differ and will be specific to every organization.

If you would like a recommendation of how to deploy the virtual services or API mocks specific to your project, please contact help@trafficparrot.com and we will be more than happy to assist you.

3 ways to deploy and share virtual services and API mocks

There are three common ways you can deploy and share your virtual services or API mocks.

The first one is where you reuse the same hardware and virtual service across many users, see Diagram 1.

What you see in Diagram 1 is an organisation that uses a DEV environment to deploy a Legacy Banking Application. That application needs to connect to, among many others, a payment service. The DEV environment is connected to a payment virtual service, that is running in a service virtualization tool deployed on a virtual machine. That same virtual service is shared with two more users (or agents if you wanna call them that). The Jenkins slave is running build jobs (pipelines) of that same Legacy Banking Application and connects to the shared Payment virtual services. We also have a QA that is testing a new microservice on her laptop, that requires connectivity to the Payment service, and she is using the same shared Payment virtual service.




The second one is where you reuse the same hardware but create a copy of virtual service per user, see Diagram 3. The three users/agents (DEV environment, Jenkins Slave and the QA) are using three copies of the same Payment virtual service, running on the same shared virtual machine.




The third option is where you use a copy of virtual service per-user, but deploy it per-use instead of using a shared environment, see Diagram 3. In this case, each user/agent uses a copy of the Payment virtual service that is for their exclusive use. So, the DEV environment is connected to a Payment virtual service running in Docker on OpenShift in the internal cloud. The Jenkins Slave is spinning up a Payment virtual services just before running the tests of the Legacy Banking Application. And, the QA is spinning up a Payment virtual services on her laptop.


Please keep in mind, these are only examples to demonstrate what our clients do, the details can differ and will be specific to every organization.

Traffic Parrot is not recommended in Diagram 1 and 2 style deployments

Firstly, if you want to do Diagram 1 or Diagram 2 shared deployment style, we recommend using other commercial service virtualization tools instead of Traffic Parrot. It is possible to use Traffic Parrot in those environments, but we do not recommend it.

Traffic Parrot is recommended in Diagram 3 style deployments

If you would like to use distributed deployment, similar to the one described in Diagram 3, we recommend using Traffic Parrot.
If you would like a recommendation of how to deploy the virtual services or API mocks specific to your project, please contact help@trafficparrot.com and we will be more than happy to assist you.

Tuesday, 6 August 2019

Traffic Parrot 5.3.1 released, whats new?

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

Features

  • New operating system specific release with bundled JRE:
    • Any operating system with no bundled JRE: trafficparrot-no-jre-5.3.1.zip
    • 64-bit Linux with bundled JRE: trafficparrot-linux-x64-jre-5.3.1.zip
    • 64-bit Mac with bundled JRE: trafficparrot-mac-x64-jre-5.3.1.zip
    • 64-bit Windows with bundled JRE: trafficparrot-windows-x64-jre-5.3.1.zip
    • 32-bit Windows with bundled JRE: trafficparrot-windows-x86-32-jre-5.3.1.zip
  • New state management REST API for global state:
    • Create or update state using PUT /api/state/global/{name}
    • Get state using GET /api/state/global/{name}
    • Reset all state using DELETE /api/state
    • See the OpenAPI documentation or import the Postman workspace for more information on the API usage
    • {{ manageState 'example' 'set' 1234 }} to set a variable in a response template
    • {{ manageState 'example' 'get' }} to get a variable in a response template