No-Brainer HTML, JS, CSS and testing starter tutorial — Part 8

This tutorial series is aimed as notes for participants of the workshop which will be held in OKE Software Poland. It assumes that participants have very basic understanding of HTML, CSS and JS technology. It doesn’t provide complex overview of current frontend state of the art, but rather should be treated as encouragement to further pursue the knowledge needed to become frontend dev or automated tester.

Testing search header

In this part, we’ll start by testing our search input. As I am moving further with cypress, I really appreciate what it has to offer. It takes a little bit of time to get your head around it, but it’s so worth your time.

We can take a look at the search.feature to see what we’d like to test. We won’t be following it 100%, though. Still, there’s a plenty to test. Let us start by creating the search_spec.js file in integration folder. We’ll start with testing the input element existing and having the proper placeholder:

We use .should function which has a very rich set of matchers. Here we use it to check the placeholder attribute for given value. Next, we can check that our button exists and has a correct text:

How about something a little bit more complicated? We’d like to test that our filtering/searching feature actually works! How about testing the result of searching with The searchTerm? We’d like to be sure that every single result has this term in artist field:

I really like the ability to mix the should and expect syntax when doing assertions in cypress. It doesn’t lock you in a single way to approach the problem. As you can see now, you can use should to assert on something or pass a function with additional assertions inside of this function. The last thing that I’d like to test in search_spec is actually checking if our link works and are we moved to another page:

As you can see testing the location changes is rather easy with access to location function.

Now we can move to testing the details pages. We’ll start by testing whether we can navigate to this page clicking one of the rows in our main ticket table:

From there we can start our assertions. Let’s start by checking whether we actually changed to another page:

There are some elements we’d like to check for having content. It’s rather straightforward:

Then there is another interesting test. We’d like actually see if clicking on share button increases the number of shares. We’ll use invoke method to get a hold of text from given element:

Not so hard. We store the number of shares inside currentNumberOfShares variable and then we click the button. After that we check for the value of h5 node again and compare it to the previous one. And the last thing I wanted to check here is going back to the list of our tickets:

This sums up testing the details. One thing left for us to check is the list of tickets that have been added to the users list.

Testing the user ticket list

Ok, the last and most complicated part is about testing the user ticket list. It has the most functionalities and also requires us to prepare the page with correct starting state (tickets added to localStorage). Let’s handle this:

We are going through the tickets on the home page here in addTicketsToList page and we are adding them to localStorage. Also in our beforeEach function we move to our ticket list page. After the initial state is prepared we can finally go about writing our tests. The first should check whether we added any tickets at all:

Another thing I’d like to check is if every ticket starts as not paid:

We are using each function here and wrap every single element back in cypress to get into the status text of each row. This way we can test every single row in our view.

In the next step we are testing header buttons that are affecting all tickets in the table:

Next, we’d like to check a single pay button. We test whether it changes the status of a single ticket, but not any other ticket. We can do it like this:

And of course single delete button, where we can just compare how many rows we get in the table after the operation is finished:

And last but not least, we can test if there’s a possibility to go back to our home page:

What is really great here is that we can select elements by it text content using contains function.

Wow, that was like a whole lot of testing. We definitely did not test every single possible thing, but you should be armed with knowledge to do this by yourself. I believe that will change the way we are testing the web apps. I’d love them to do something similar for React Native, but it’s a long shot. Anyway, this ends our workshop, I hope you enjoyed it as much as I did!