As PO, my last top-of-mind professional concerns’ inventory: load testing principles, starting K6 for load testing, a quick playwright discovery both with Python and Node, how-to to connect lighthouse with Cypress, how-to to test Google Analytics and Google Tag Manager with Cypress

by Posted on

I know the title sound like a clickbait, and I was about to use the F word in it, but I gave up! So, let’s start with some banalities:

  • I am often bedeviled by an intense curiosity for a subject. This blog is living proof of that. Responding to this imperative to satisfy this curiosity always leaves me bewildered… What’s the point of investigate all this when in the end you can satisfy to be ignorant and claim it?
  • Most of the topics below are explored for simplicity more than exhaustivity. So, I will certainly state the obvious on these subjects 🙂
  • It also gave a better understanding of Friedrich Nietzsche’s quote: “Blessed are the sleepy ones: for they shall soon nod off”.

Anyway, my two last top-of-mind professional concerns were:

  1. The first concern was that I wanted to extend some Cypress tests to performance testing (Frontend performance or Backend performance) more than functional testing
  2. The second was I wanted to test also some required Javascript files such Google Analytics or Google Tag Manager with Cypress preferably.

The constrain was simple: “Can I do it with Cypress only and not with a tedious integration of new tool or framework for such performance testing?” As it is p… in the a… to manage several tool Ooops!

Anyway, during this exploration, I had the chance to document:

  1. load testing principles
  2. using K6 for load testing
  3. a quick playwright discovery both with Python and Node
  4. how to connect lighthouse with Cypress
  5. how to test Google Analytics with Cypress

This post is a quick roundup of this exploration.

You can find all files on my GitHub account. See https://github.com/bflaven/BlogArticlesExamples/tree/master/cypress_playwright_lighthouse_performance_testing

# You will find these 4 directories
cypress_example_1
k6_example_1
playwright_node_example_1
playwright_python_example_1

The genuine cost

Does a tool’s genuine cost should include the time spent (learning curb) to reach tool’s proficiency? My answer is Yes.

For instance, I always try to figure out the time spent to learn a dedicated tool (K6) vs the time spent to tinker an existing and well understood (Cypress) with no success guaranteed. You see the point?

For sure, it’s when you begin to master a tool that you see its limits. As often, thanks to an event (bug, regression, error…), you cruelly realize limits and fragility for your hard-won knowledge!

Thus, I master a little Cypress and I now see that this framework that I use for E2E tests is not really intended to do anything else!

Choosing and investing in a new tool represents a tremendous cost for a team.

In my case, the constraint that applies is once Cypress has been chosen, it must at least be kept. I know that the grass is always greener elsewhere and I know also that novelty is the modern bait. Of course, it would be tempting to choose another tool like K6 or to change the E2E framework once again and choose Playwright, for example, which is the latest test framework I have heard of.

It is true that after reading a few articles; It seems obvious that what I was trying to do was obviously more like load testing or performance testing (Frontend performance or Backend performance) than functional testing!

All my knowledge come from this article! See https://k6.io/docs/testing-guides/load-testing-websites/

Load testing principle

I have grabbed some explanations on K6 website, a very famous loading test framework and so a great source of information.

The main question is “What are the load testing approaches possible?”
The answer is always when you approach the load test, first consider the following perspectives:

  1. Backend vs. frontend performance
  2. Protocol-based, browser-based, or hybrid load testing
  3. Component testing vs. end-to-end testing

So where do you stand? According to me, I don’t know exactly in which category I stand with my need but… from my understanding if I write down a user story, I will say:

“As a PO, I want to test the critical files loading and ensure that these files are “present” in the CMS (Backend) or on the website (Frontend) before I really start to test the functionalities themselves.”

To make it abundantly clear, I add that preferably, loading testing and functional testing will be written with the same framework e.g., Cypress so all actions will be chained in user stories written down in Cypress’ testing files.

Indeed, by analogy, to what is written above, it is overall logical in terms of scheduling. For instance, a lumberjack, before sawing a tree, make sure that the ax is operational, so he will not put the cart before the horse like we said! Capisce? 🤌

I should answer to K6 question above, I am right in the middle of the 3 points! Therefore, my main test is to make sure that all “critical” JavaScript and CSS files are correctly loaded to then launch an E2E test battery on an enriched editor like Gutenberg in WordPress for example.

Like often, at the same time, by exploring this loading test question, I have explored 2 but secondary testing issues:

  1. First secondary test is how to make sure that Tag Commander is correctly loaded because all users’ actions are tracked down in Google Analytics.
  2. Second secondary test I want to leverage on Google’s Lighthouse directly through Cypress.

For those who wonder what Google’s Lighthouse, here the baseline extracted from the official website.

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO, and more.

Source: https://developer.chrome.com/docs/lighthouse/overview/

Few words on Playwright with Node

My idea was once again to measure the qualities of playwright. For the comparison conditions to be identical to test frameworks such as Cypress, CodeceptJS, it is this version of playwright with Node that must be installed. The logic of playwright is then remarkably close to the ones mentioned above.

Few words on playwright with Python

I found much interest in working in Python as it is often the “on-top language” that drove my own automation. By the way as I often say, it is much interesting to learn Python instead of Ruby or Bash because you can thousands of things in Python, since is become a standard for data-science or for Google, the language Go may have my favor one day. For Go is the coming underdog!
Anyway, apart for the digression on programming, for testing framework, you must deal with JavaScript! And to make a true comparison of playwright between Cypress, CodeceptJS, you need to use the distribution made on Node. According to me, thought quick search, there are much more resources for playwright node on GitHub that in Python.

More infos

Published by Bruno Flaven

By now, Bruno Flaven works as AI Coordinator. He has been a project manager in a wide variety of Internet business applications both in Mobile and in Desktop for 20 years now. You can find more information about his professional life on his personal website (www.flaven.fr) or his linkedin profile: https://www.linkedin.com/in/brunoflaven. He is currently working In France Media Monde (FMM) mostly on mobile applications (iOS and Android). He has also worked as P.O for a Backoffice project made with Symfony. He also made few trainings to facilitate the handling of the tools that he helps to make.

Related Posts