
- OVERVIEW
- Languge: JavaScript
- IDE: VSCode
- Runner: Cypress Runner, called from NPM
- Source Code Management Tool: Github via Github Desktop
- Type of Tests: UI / Web browser automation
- Websites Tested: Opencart and todomvc
Intro
This blog continues my journey of creating a test automation portfolio, which I started back in at the start of August (aka that time when it was occasionally sunny and not just bleedin damp and cloudy all the time!). This time I wanted to talk you through my exploits using the increasingly popular web browser end to end automation tool Cypress. I’d heard quite a few people say this tool was easy to pick up with lots of great documentation, so I thought I’d give it a go.
The Project
By now you won’t be surprised to hear that I did what lots of folk, both experienced and newbies do when starting using a new tool – I magpied, and yes, that is an actual noun, who knew! My sources of information including code were:-
Gil Tayar’s “An Introduction To Cypress” Tutorial on Test Automation University (note this was created a few years back and some features of the tool e.g. cross browser execution have moved on since, code base is still solid though)
Marie Drake’s wonderfully easy GitHub Repo On Cypress Fixtures and Login Example Code
Toby Steed @ Learn Automation’s series on Cypress including a very handy cheat sheet
I decided to focus on two learning sites – todomvc as per the original TAU course material, and Opencart’s demo website, as this gives lots of scope to add new tests in future as my familiarity with the tool grows.
Key Features
I wanted to develop what was already in the repo to support my learning by:-
- Install the original repo from the TAU course, and get it up and running.
- Get the existing tests to run
- Add in Marie’s login tests
- Refactor them to work against the Opencart website
- Add in a few new ones based on the extensive Cypress docs and Toby’s cheet sheet

I did indeed find Cypress an easy one to pick up and get working, a few NPM commands from within the VSCode terminal is all it took. There aren’t any libraries to import as cypress takes care of this for you, as well as adding a load of useful example code. So far so good.
Another handy feature, although I’m told its not the best idea to rely on this exclusively, is using the Selector playground to identify and copy Cypress elements – or even the full Cypress command – which can then be inserted directly into your code. Tidy. Here is a video:-
As far as the code itself goes, its a new syntax to get used to, but fairly readable, and adding the reference types code at the top of the page ensures if you do get stuck examples are only a hover away:-
/// <reference types="cypress" />
describe('todo actions', () => {
beforeEach(() => {
cy.visit('http://todomvc-app-for-testing.surge.sh/');
cy.get('.new-todo', {timeout: 6000}).type("Clean room{enter}");
});
it('should add a new todo to the list', () => {
cy.get('label').should('have.text', 'Clean room');
cy.get('toggle').should('not.be.checked');
});

The Code
I tried to learn from my earlier mistakes here, and just started my own repo from scratch. I am really getting used to the Github Desktop app, which personally I prefer to the new CLI.
You can take a look at my code on GitHub here.
Here’s a visual of the key elements:-

To run the tests, simply go to the terminal window (terminal -> add) in VSCode, navigate to the correct folder and type
npx cypress open

This then brings up the in-built Cypress testrunner, which is a nice UI interface you can use for execution. I tested the code against a number of browsers by using this dropdown and selecting the relevant spec (Firefox is now officially out of beta as per release 5.3.0):-

This video shows me executing the login tests using Cypress UI. Take a look at the very clear step by step results panel on the left hand side which you can actually use to rewind through the history of your test execution to see what was happening at each step, which is another user-friendly feature:-
Lessons Learned
The more I work on this stuff, the more I see appreciate that getting a framework off the ground is the easy bit. The hard part comes when refactoring tests, and coming up with a structure to make them as maintainable as possible – also doing those tricky edge cases which take up 80% of your time but are only 20% of your tests.
Just one last repo to create, and I’ve saved it til last on purpose, Selenium Webdriver.
Wish me luck!
2 thoughts on “Creating A Test Automation Portfolio Episode 5: UI Web Browser testing using Cypress”