A Day with Cypress Part 2

For those of you who are here because you read Part 1 of A Day with Cypress, welcome. For those who haven’t yet read it, why not head back and join me from the beginning of this journey. If that’s not for you, and you like to go rogue, welcome, but don’t expect a ‘last time on…’ style intro, you’re coming in hot!

In Part 1 we stopped before getting to points 2 and 3 of the list of objectives I’d set myself on that fateful day. So we’ll rectify that in Part 2 by covering item 2 in the list.

  1. To put a Cucumber implementation on top to author the scripts
  2. To look again at stubbing calls at runtime
  3. To look at using snapshots instead of explicit assertions

One of the fantastic features of Cypress, and a real USP when comparing it to a Selenium based library, is that it runs within the browser and has access to the javascript that your application is built from, at test time. This provides users with a whole host of possibilities to solve testability challenges, for which we would otherwise need to find alternative and potentially clunkier solutions. Injecting test data is one of those testability challenges. I’m going to guess that most software testers can recall a time in their career when they’ve hit their heads against a brick wall trying to get good test data in to their application.

It would appear the team at Cypress have experienced this themselves because it’s one of the most useful parts of their library. Cypress comes with the ability to intercept and replace some requests at test time and above all it’s really simple to start using. Let’s look at an example.

Testing the UI or Through the UI

Being cheeky I’ve picked the Royal Mail Find a Postcode feature to demonstrate this. When using the feature, as you type in to the text box, each letter you type will initiate an XHR request which, based on the post code you’ve begun to enter, returns a suggested list of addresses to show to the user.

As the user types in to the text box, we see that each letter typed sends a new request for suggested addresses.

When it comes to testing this feature, I might consider the following sample of identified risks:

  1. When I type, the expected request isn’t sent to the service
  2. When we get a response, it doesn’t contain useful information
  3. The UI doesn’t render useful information appropriately

Risk 2 doesn’t need the UI to explore and verify. I could quite happily send requests to the end point, using a tool like Postman or writing some code and process the response. This will give me the same level of confidence in what I discover as it will if I had I tested ‘through’ the UI. Amongst other things, by removing the UI from the process, I reduce the complexity of the setup and reduce the risk that something in the UI blocks my testing.

However, risks 1 & 3 are tightly coupled to the UI. If the UI isn’t mapping the typed text to the request to the service correctly, then that is a UI issue. Similarly, if the UI doesn’t render the appropriate information to the user based on the response from the service, then that is also a UI issue. So, based on the assumption (as explained above) that I don’t need to test through the UI to test risk 2, then I can make the logical assumption that I don’t actually need the service to test the UI.

In summary:

If I only want to test the UI, then I may not need the integrated service to be up and running. However, I do need the information that is going to be processed by the UI.

In setting this principle, we achieve another benefit and that is one of determinism. For any check that might go in to our pipeline, we want to reduce the potential for noise (unwanted or useless information) as much as possible. Checks should fail because we’ve introduced a problem, not because our test data and setup isn’t deterministic.

There are many ways we can achieve this:

  1. Using hand rolled local stubs which we proxy a locally hosted version of the UI to
  2. Using a hosted service such as GetSandbox,  configuring the application or environment to point to a different service end point or address
  3. Seeding data in to the integrated service and therefore completing a fully top-to-bottom information loop.

Cypress allows us to do option 1 but really easily. All we need to do is add to a script steps 1 & 2 below and configure them to intercept the appropriate service call and replace the response.

  1. Start up the Cypress routing server with cy.server()
  2. Define a route that you want to intercept with cy.route()
  3. Execute the actions necessary to get the UI to send the request
  4. Assert on the expected outcomes

All good in theory but I know you’d like to see an actual example.

Testing the Address Finder

To configure the steps correctly we need two additional pieces of information:

  1. The request that’s going to be sent to the service
  2. An example response that we want to modify to suit our needs

In this case, if the user types ‘s’ in to the text box, the following request is sent to the service:


The request also contains a number of parameters, but I’ve omitted them for this example. If you want to explore more, you can find this yourself using the Network tab of your favourite browsers Dev Tools.

The response from that request contains an array of objects. Each object looks like this:

  "Text":"South, Pannels Ash",
  "Description":"Pentlow, Sudbury, CO10 7JT"

Through a little reverse engineering, we can see that the Suggested Addresses list displays the Text and Description properties of each of the returned objects. *Ideally, if you were working on this feature, you’d not have to guess this.

So taking a really simple test case:

Given the user is on the ‘find a postcode’ page
When the user enters ‘s’ into the text box,
Then we should be shown a suggested addresses list that contains the expected addresses for ‘s’.

As discussed, this isn’t great if you’re using a fully integrated system and can’t control the information that you get back. So instead we should author the test case to suit our testing needs, then tell Cypress to help us achieve the setup needed.

Our test case now becomes:

  Given the user is on the 'find a postcode' page
  When the user enters 's' into the text box
  Then we should be shown a suggested address
    of 'Buckingham Palace'
    with text 'Where the Queen Lives'

Let’s look at the code, starting with the step definition for the When step.

When('the user enters {string} into the text box', (postcode) => {
    delay: 1000




Let’s look at what we’ve got. Firstly there’s a call to cy.server which we’ve configured to have a 1000ms delay before any response is provided. In this case I’m using the delay to emulate a slow round trip from request to response. It’s not necessary for this example but it helps to demonstrate a pattern explained later on. Once the server is up and running, we then need to specify a route that we’d like to intercept. To setup a route for our needs, we need to first help it identify the correct request we want to manipulate. There are three ways to pattern match a URL for a request: exact strings; regex and glob. In our example I’ve asked the route to ignore the top level domain and any parameters.

Now that we know how to intercept the request, we need to know what to do with it. cy.route is a very extensible method, allowing the user a number of options to satisfy the testing needs. We can inline responses directly into the method, but unless you’re replacing the response with an empty object {} then your code is going to look quite clunky. Your second options is to pass in a callback which will be called when the route is intercepted, allowing you access to the response data and manipulate it as needed. Option three is the one I’ve used and Cypress call it Fixtures. A fixture, in its basic terms, is data in a file. This is a powerful technique because it helps you manage potentially complex JSON objects away from your code but makes it really easy to use them.

As you can see, I’ve configured cy.route to replace the response with the contents of the fixture ‘bPSuggestedAddress.json’. This file lives in the folder /fixtures and contains the following object

      "Text":"Buckingham Palace",
      "Description":"Where the Queen Lives"

Dead simple I’m sure you’ll agree. We’ve also given this route an alias. These are nice little shortcuts that can be later referenced in code, and they also turn up in the Cypress test runner, so are great for marking up steps to easily find them.

Continuing the step definition, we type the letter ‘s’ into the appropriate text box and then ask the step definition to wait until the response has been intercepted. Remember that alias I just mentioned? Well because I’ve set up the route with one, I can now ask Cypress to wait until that alias has completed. Don’t be afraid to do this. Remember, this isn’t some arbitrary wait which could be indefinite, instead it will wait for exactly the time we’ve specified. In this case we’ve put in a delay of 1000ms for the server to intercept our request and send back the desired response. If we hadn’t put in a delay, that response would be sent back immediately.

And that’s the step completed. The last step in the script is:

Then we should be shown a suggested address
    of 'Buckingham Palace'
    with text 'Where the Queen Lives'

And here’s how I’ve implemented it:

Then('we should be shown a suggested address of {string} with text {string}',
  (address, text) => {
    expect(cy.get('body > div.pca > div:nth-
      child(4)').children().should('have.length', 3))
    cy.get('body > div.pca > div:nth-child(4) > div.pcaheader')
    cy.get('body > div.pca > div:nth-child(4) > div.pcafooter')
    cy.get('#cp-search_results_item0').parent().should('have.id', 'cp-
    cy.get('#cp-search_results_item0').should('contains.text', address + text)
    cy.get('#cp-search_results_item0 > span').should('have.text', 'Where the
      Queen Lives')

These are all specifics related to how the ‘suggested addresses’ component works, so don’t worry too much about them, but I think we can both agree that it looks quite clunky and I definitely know that there’s some parts of the expected implementation that I’ve not covered. Which begs the question, how can we do that better? In Part 3 of this series, I’ll take you into the realms of snapshot testing. If you’re familiar with component based snapshots with Jest and Enzyme, then you’ll have a good idea of where this will go.

So there you go, you’ve now learnt how to use the basics of request and response manipulation with Cypress. It’s not a tool that you’ll want to use all of the time, but in the right situation and the right context, it’s an extremely powerful addition to your tool box. Also, because it’s so simple and quick, it’s a great tool to actually aid testing (not checking). That means you can use it to help you when you’re exploring the application and want to run ad-hoc experiments on your application. If some of those experiments end up as pipeline checks then great, but don’t feel the need or to be pressured into assuming that every piece of automated testing code you write has to go into the pipeline, but that’s another post for another time.

Thanks again for reading and I do hope that you found this useful. Please leave your comments below.

I’ve also considered turning these into vlogs, so if that’s something you think would be worthwhile, please get in touch and let me know.

Why I like Testing in Production


This post is not a internal environment vs production environment face off nor is it an attempt to convince you to change your beliefs on testing in production.

It is an attempt to show, that testing in production can be another tool in the testers arsenal, to be used when the context fits and if the team you’re working with have the capability to do so now, or the desire to build that capability for the future.

If it does encourage you to investigate what testing in production might look like for you, share your story, I’d love to hear it.

But you should never test in production…

There is a school of thought which prescribes that testing of an application should only be completed in internal integrated environments.

I’ve recently seen a post discuss control – that new processes should never be tested in production. I’ll often hear about increased risk to the business and customers through shipping unfinished features. Occasionally someone will accuse me of treating our customers as guinea pigs.

Not forgetting data, I’m told that there’s a risk that my testing will be skewing production analytics for customer engagement, account tracking and stock levels if I’m testing in production.

These are all valid risks in their own context and each introduces varying degrees of impact should they realise. There is no wrong in any of these arguments.

Where would you prefer to test?

Ask yourself, given zero risk, would you ever test in production for any reason?

My answer for this is, given zero risk, I would test everything I could in production. I would test new features, integrations of new features with old features, integrations of my application with other applications and dependencies. I would also conduct all of my non-functional testing in production: performance, load, security, etc. Why would I use an approximation of the live environment if I could use the real thing?

But of course zero risk doesn’t exist, so I’m going to take my utopia and start to break it down until I find a level of risk that is suitable for the context in which I would like to test. As part of that exercise, I would need to be clear on what I mean by testing in production.

I define testing in production to be an encapsulation of two distinct states.

  1. Testing in production of an as yet un-launched, hidden version of the application that customers cannot see or use
  2. Testing in production following the launch of a new version of the application to customers

Both activities offer their own value streams but solve very different problems.

Everyone can benefit from and should think about spending some time with number 2. Your application is live, your customers are using it. Assuming you could learn something new about what you’ve already shipped or even test out some of your earlier made assumptions, why wouldn’t you want to do that in production? Run a bug bash in production, keep it black box (only things customers can do) if you’re particularly worried about it and observe. You may find something that’s slipped through your net and if you do, you’ve proven its worth.

Testing hidden features

It’s option 1 that I find most interesting. I’ve recently read an article introducing testing in production from the Ministry of Test Dojo – Testing in Production the Mad Science Way The article discusses two distinct models that you can implement to provide you with the means to test in production.

We’ve implemented a variation on the circuit breaker method referenced in the article. In doing so, we have the ability to use feature flags to determine which code path the application should go through and therefore, what behaviours the customer has access to.

In its default state a feature flag is set to off. This means that the customer sees no change despite the new code having been deployed to production. When it’s there, our circuit breakers allow us to turn features on client side. This means that testers can go to production, set the feature flag to on for the feature they want to test and are able to happily test against production code for the duration of their session. Once testing is complete and the feature is ready to go live, we can change the configuration of the feature flag for all customers, safe in the knowledge that we can turn it off again if something were to go wrong. The deployment of configuration is quick and we have two mechanisms to permeate the rollback to our customers – either slowly as sessions expire or we can force them through on their next page load. When rolling forward we only do so as sessions expire.

In shipping this changed code we make the assumption that we’re able to determine whether the introduction of this new code has not had a detrimental impact on the current feature set and customer experience. We derive this confidence through testing during the development phase of the new feature and through our automated checking suite which runs in our pipeline. We also have a third line of defence, a set of automated checks for our core journeys, created by a central team who own our path to live.

This mechanism takes time to mature and we’ve definitely made a few mistakes along the way. With perseverance we’ve been able to ship fairly large changes to our production site, with no impact to customers, test those changes and then turn them on when we’re confident we’re ready to.

Whilst we can mitigate concerns such as customer impacting stock levels by being careful to only use non-low stock items, there are still some structural areas which we do not test in production such as peak load tests and updates to our feature switch and rollback/roll forward mechanisms. Anything else will be considered on a case by case basis, discussed during 3 Amigos within the team(s) and agreed on before actioning.

My thoughts

For some contexts, I prefer testing in production over testing in internal integrated environments because it provides me with these key benefits :

  1. The likelihood of my testing being blocked by an issue with a dependency is greatly reduced
  2. The data is at peak scope, complexity and usefulness
  3. Any bug that I find in the application under test is an actual and real issue 
  4. Any issues that I find with the environment will be having real impact to our customers and/or the business

In my experience, these benefits derive from flaws with the practices put in place to build and support internally integrated environments. 

Internally integrated environments do provide their own benefits. There are scenarios and processes which I would be reluctant to test in production and I’ve outlined some of those above. This article also does not discuss inside out testing techniques such as those on code – unit tests and component tests.