E2E Test Experiments With Cypress

Cypress is a free and open source end-to-end testing framework which is easy to set-up and easy to use. It executes the tests in the browser so more like Selenium tests but way easy to start with. It is built on top of Mocha and makes asynchronous testing fun. 

This post is a simple tutorial for anyone who wants to explore the benefits by comparing your current test suite to Cypress.

To write a test, I need an app as well. I am just going to use React’s create-react-app library which will give me a react app that runs on localhost.

Create React App

Prerequisite: You have Node and npm installed on your machine.

  • Now install create-react-app by running npm install -g create-react-app. This will install the create-react-app dependency globally.
  • Create a directory and cd to it.
  • Run npx create-react-app . This will create the project.
  • Now if you run npm install and npm start, It will start the app on port localhost:3000

Write tests for your app

In the project directory, run npm install cypress --save-dev . This will add cypress dependency in your package.json

Now that we have cypress installed, run command cypress open that will launch the cypress GUI and will ask you to create a pre-defined skeleton that cypress uses. Accept and that will create a directory called cypress with other useful sub-directories. Some of them are used for the following purposes:

  • Fixtures – we keep test data related to tests inside this
  • Integration – For writing test specs.
  • Custom commands inside Support folder.

Delete everything inside integration folder and create your first test file (example.spec.js) and write your first test.

In my test, I am just going to navigate to localhost:3000 and verify that react app is loaded. This is how it looks.

Test Execution

There are two ways to run tests:

Run cypress open. This will open the interactive console and you can run the tests by running the spec file.

Cypress GUI
Test Execution From GUI

Run command npm run test:integration to run it from command line. It will launch cypress, run the test and close cypress.

Take a look at full source code on Github.

Hoisting in JavaScript

What is Hoisting in JavaScript?

The dictionary meaning of hoisting is – raise (something) by means of ropes and pulleys.

That is what JavaScript means by hoisting. It pulls all the variable and function declarations on top of your code. Well, not literally. It moves the declarations to top during code compilation so the decelerations are available before initialising the variable or invoking function.

Let’s try to understand this with some examples:

Using variable before declaring

Invoking function before defining

Though, We should keep in mind that hoisting pulls only the declarations to top and not initialisations. So, the below example will always log `undefined`.

Best Practices

Though you get hoisting for free but the best practice says that we should always declare our variables and define our functions before using them and invoking them respectively in order to save ourselves some mess. Also, declarations first approach will make life easier during debugging.

The Insightful Side of Software Bugs

If there is one thing which people in Software Engineering don’t want, it’s a software bug. No-one wants the experience of fixing bugs. Well, somehow it’s true outside software engineering as well. Your end users don’t want to see that bug as well. Think about how your competitor can misuse/abuse that bug against your company and I am talking about all kinds of bugs i.e. functional, security vulnerabilities etc. I believe, no-one wants an emphasis on how they can actually turn ugly. You certainly don’t want the misuse. Do you?

Well, only if wanting things would had made them possible, this World would be a peaceful place because a lot of people want World Peace as well.

It requires looking beyond the problem and finding the brightness in dark.

It often requires hard work to make things possible. It requires looking beyond the problem and finding the brightness in dark. It requires balanced understanding to not think software bugs as something which slows us down to release those features. I am not advocating software bugs as a metric here. Testers’ capabilities should not be judged on the basis of number of bugs one finds. My point is anyone can find software bugs but what do you do with those bugs and when you find them in the development cycle, is important.

Looking Beyond The Problem

So, How do you look for that motivation when it comes to Software Bugs?

Just documenting them in backlog is not enough. The real value of bugs is about what they are trying to tell. Those things can be used to convince people towards fixing bugs. Every bug has a context and if people understand the context better, it can be used as a learning path for not letting the similar type of issue happen in future. There might be a possibility that everyone does not understand the context and that’s okay and that is why teams should communicate and understand the context.

There are few questions which we can ask ourselves and our teams during bug prioritisation which would give a deeper insight or understanding a bug or at the very best, they might give you a direction to not think bugs as your enemies and resistance.

Those questions could be:

  • Is this a requirement or design flaw or could it be avoided with the greatest tool given to humankind aka communication?
  • How could have this been caught earlier? Could any type of test (unit | pact | integration | <insert type of test>) have caught this?
  • How will this affect the end customers if we release this? Will they give a happy, sad or meh reaction?
  • If the bug is discovered in production, how can it be fixed properly and not just a dirty quick fix?
  • What affects will it have on Company’s branding?

I can actually cite an example here for affect on company branding. I used to use a website. After GDPR came, they also implemented GDPR by using ‘accept terms and conditions for data’ solution to follow the law. But, the way they created this functionality, is a pain. So, this is what happens over time when you go to the site and not logged in.
– You are being presented a pop up with GDPR jargon.
– You Select the T&C and proceed.
– After some time, the same popup is presented again with unchecked policies and after accepting the second time, eventually, you are logged in.

The functionality is clearly broken here. Why do we need to show accept T&Cs every time an existing user logs in. It takes ~3 mins every time someone wants to log in. Also, an unnecessary frustration as an additional perk. 

Next time, you discover a bug, try to find the symptoms in the system and see beyond the actual bug.

If you are still with me, I will leave you with this interesting article which has many examples of how software bugs ate the World.