One of the main differences between mocking and stubbing is the ability to verify the behaviour of test doubles. Mocking lets you isolate the class under test, and verify that the expected actions on dependent interfaces were triggered.

Thanks to Hoverfly Java's support for JUnit - and its DSL - creating an HTTPS server for testing is a breeze compared to the existing Java solutions. I also get the added bonus of a powerful API simulation tool which can be used to simulate the target server endpoint.

Following the latest release of Hoverfly Java, I would like to give an overview of the new DSL, which allows you to create stubs for HTTP APIs using Java code instead of JSON. I will discuss some of the advantages of doing this and also some of the trade-offs, with comparisons to alternatives such as MockRestServiceServer, Wiremock and Betamax.

Many modern DevOps/sysadmin tasks are based around the creation and maintenance of a ‘platform’ and supporting tooling. The primary purpose of the platform is to support self-service and automation for the development team, which ultimately allows developers to focus on what they do best - creating code to add business value - rather than being overburdened by operational concerns.

Testing microservices becomes a daunting task as the system topology grows. When microservices are chained together to realise business functionality, it is tempting to verify that they are working together by writing integration tests. If you go down this path, you will need to have all your applications, the underlying resources (such as databases, S3 buckets), and third party APIs wired up and running in a known state just to ensure that "service A" can talk to "service B".

The SpectoLabs team presented a microservices testing workshop at the recent TestWorksConf conferencein Amsterdam, and we are keen to share both our experiences of the workshop and also our materials under Creative Commons so that others can re-use them.

The SpectoLabs team are pleased to announce the next iteration of our workshop 'Automated Testing in a World of Interdependence: Service Virtualisation for the Modern Age' will be running at Xebia's TestWorks conference in Amsterdam on the 7th October 2016.

One question we get asked a lot at SpectoLabs is why our open source Hoverfly service virtualisation tool only supports HTTP/HTTPS, and not protocols such as JDBC, ODBC, AMQP, MQ etc. This is a good question, and the honest answer is that as a startup we have to choose carefully where to apply our development resources, and adding support for each additional protocol is non-trivial at the code level.

Here at SpectoLabs HQ we have been working alongside our friends at OpenCredo to help several organisations build and deploy microservice-based applications. Most of these organisations are looking to migrate away from (or augment) their current monolithic application, and we’ve also been involved with a few greenfield prototypes.

Recently, SpectoLabs hosted a focus group in Amsterdam with some of the Netherlands top software test engineers. During the evening, one of the engineers told me a story. After some persuasion, he gave me permission to retell this story, with the caveat that it must be used to teach others how to avoid the unfortunate events that haunt him to this very day.

In order to be able to regularly release an application, your automated tests must be set up to give you fast and reliable feedback loop. If bugs are only found during a long and expensive multi-service or end-to-end test run, it can be a hinderance to fast delivery. Unfortunately I have often seen this problem in development environments: a huge suite of clunky, flaky and slow end-to-end tests which test the full functionality of the application as opposed to being more lightweight and reflecting basic user journeys.

Continuous Delivery is generally considered as one of the most effective ways of reducing delivery times and improving quality, however adapting to its disciplines can be costly and difficult, particularly for large projects. The problems can escalate to become blockers when enterprises wish to adopt the methodology, but to reap the benefits of Continuous Delivery, you cannot compromise on its principles.

At OpenCredo and SpectoLabs we’re helping a lot of organisations embrace the microservice architectural style. One problematic pattern we repeatedly see when organisations are migrating from working with a single Java-based monolith to multiple microservices is the development team stumbling with orchestrating multiple services for local development and pipeline-based automated testing.

Every other Wednesday I travel from Amsterdam to London and back. I somehow always resented ‘wasting’ those two hours in the air (not to mention the trains to and from Gatwick but that’s another story entirely) so until recently I would fill the time with reading, even though what I really wanted to be doing was working on one of our pet projects which will be receiving lots of attention in just a few weeks and requires that I get a move on.

I've been working in IT for more years than I like to admit and one of the greatest frustrations is the corporate mindset that leads to If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail. I've seen vendors being forced to needlessly replace one database technology with another, or over-elaborate RFPs resulting in a costly and over-engineered acquisition. Feeling charitable, I'll opine that such RFPs arise from a culture that ensuresyou only have one chance to get it right!