When I say that a decade ago, the web wasn’t the same as it is today, would you agree?

Yes, you might, or you might not.

But when we examine the statistics a conclusion can be made: Web is changing all the time and testing has accompanied the change with it. 

Testing is one of the critical processes in application development. The success or the failure of the application entirely depends on it. 

Cypress is one such framework which helps you conquer any type of web testing and is the best option for your website. 

Yeah, you must be wondering that why out of all the testing software in the market I enlighted Cypress. 

Well, let’s find out why. 

Why Cypress?

Cypress is a javascript based end to end testing framework that does not use selenium at all. 

Now, What is selenium?

Well, Selenium automates browsers. What the user does with that power is entirely up to them. Primarily, it is used for automating web applications for testing purposes. It is the core technology in countless other browser automation tools, APIs and frameworks.

So coming back to Cypress, the testing tool is a modular, integrated document assembly and delivery system that improves the management, accessibility, and distribution of content throughout an enterprise. This system can swiftly deploy and it requires little or no user training.

Cypress comes with many handy advantages which would make you choose the software at one go. 

• Automatic waiting: Cypress has the ability to automatically wait for the DOM (document object model) to load, make the elements visible, allow the animation to be completed, and much more. 
   
• Real-time Reloads: Cypress is smart enough to understand that after saving a test file the user is going to run it again, so it automatically triggers the run next to the browser as soon as the user presses to save the file. 
   
• Debuggability: The testing framework provides the user with the ability to directly debug a particular app under test from chrome Dev-tools. It presents a straightforward error message and recommends the user on how they should approach it.
   
• Architecture: There are many testing tools which work by running outside of the browser and it executes remote commands across the network, but Cypress is the exact opposite. This testing tool is executed in the same run loop as the application.
   
• Works on the network layer: Cypress runs at the network layer by reading and changing web traffic. This allows the testing tool to not only change everything that is coming in and out of the browser but also allows to change the code that may interfere with its ability to automate the browser. 
   
• It is a new kind of testing: Cypress has ultimate control over the applications, the network traffic, and native access to each host object that unlocks a new way of testing ( this has never been possible before)
   

How is Cypress different from Selenium?

	Cypress	Selenium
Installation	No configuration is needed. All the dependencies and drivers are automatically installed with .exe	Installation of  the language binding and configuring of the drivers is required
Running Against Browser	Cypress only supports chrome	You can run your text against any browser
Architecture	Runs inside the browser and executes in the same loop	Runs outside the browser and executes remote commands
Speed	Test code runs alongside application code. Therefore generates an extremely fast test.	Automation scripts are slow in selenium
Wait for the Elements	Cypress runs in the browser and knows what is happening. Thus you don’t have to wait when you are using Cypress	In order to do effective automation waiting for an element, it is an important task
Documentation	The team of Cypress has invested a lot of time in documentation hence it is seamless and complete.	The documentation is not complete and difficult to understand.

Limitations and challenges faced in Cypress 

While Cypress does a really great job of giving developers and QA engineers the thing they want in an automation tool, it does have some limitations.

• Since the structure is very different from selenium end to end tool, the user first needs to understand the structure and then find the best way to create the scripts.
   
• As the testing framework is comparatively new, the community is small. It becomes really challenging to find the answers to the problems. 
   
• No file upload is supported by this software and Cypress does not support cross-browser testing also. Nobody knows that when these things would be covered, and for what big projects, these features are really important. 
   
• Cypress follows the approach that is related to the Page Object Model and this has been proven with time. 
   
• The entire framework is only available for one client and i.e javascript. Thus, to work with it, it is important for the user to know the framework.

Can end to end testing deliver quality benefits?

Yes, end-to-end testing is really important it helps ensure accurate functioning of the application by testing it at every layer, right from the front end. Several other benefits of choosing and performing end-to-end testing can be because:

• It ensures complete correctness as well as the health of an application: In end-to-end testing, the application is tested and validated at all the layers. The layers include-data layer, business layer, integration layer and presentation layer which guarantees the well-being of an application.  
   
• It increases the reliance of an application: End-to-end testing increases the reliance and the performance of an application before its releases as the application is tested across different endpoints from different devices.
   
• Decreases the future risks that might accompany the process: End-to-end testing presents the user with rigorous iteration and sprint. Thus, there are lesser chances of risks and failures that may come in the near future. 
   
• It decreases the repetitive effort: The application is tested thoroughly, thus there is no looking back. The testing reduces the chances of frequent breakdowns and repetitive testing efforts 

End to end testing with Drupal

Cypress makes it easy to add new tests to the website as the user iterates the codes. Here are some of the few concepts that can help you with your Drupal Website. Let’s start the concept with: 

Setting up 

With the help of the standard installation profile and Drupal 8 distribution, the installation can take place along with JSON API. Drupal 8 comes with RESTful Web services which can serve many purposes and facilitates things such as querying nodes by field. 

There are few options for installing Cypress, out of which one of the preferred option is through NPM pacakage.json. The first step is to create your own file in the root of the project. Once the file has been placed, install it by running npm i from the project route. 

The first Test 

After installing cypress with the help of NPM pacakage.json installed, it is the time to test if it is working properly or not.

The test does two things:

• It visits any website’s root address (that are configured by NPM script)
   
• It verifies that the page has an element with “Cypress Testing” in it.

Creating the account 

The next step is to create user accounts. Depending on the environment, some option is more feasible than any other. Therefore, in order to do things, it is important to create Drupal entities. It is also important to access to an administrator account. You can do it manually create them in the database and pass the account credentials to Cypress through an environment variable, or you can let cypress create the account every time it runs the tests. This would reduce the chances of risks and issues that might occur during the procedure. 

The command that is there in cypress i.e cy.exec() provides the user with the access that is there in the system commands (Especially in Drush). The credentials are then decided for the test user. An object is added with the key values that are passed to the test as environmental variables.  Now add username and password to create the user admin account. Now that the credentials are available, it is possible to use them to create the user. 

Logging in 

To test any restricted or authentic users, it is important to log in first. The most obvious way to do this is the same way a user would log in, through the UI. In fact, the user should ensure that logging in through UI is possible. 

After each and every test, Cypress leaves the browser in a state it was in when it finished running the test. It is useful because it leaves a great position to discover the next steps. For this particular case, Cypress will come back to the browser with admin user logged in.
 
To keep tests independent from each other, Cypress removes the browser cookies before east of the test is operated. This prevents the side effects between tests, but it also means that the user needs to log in each time a test operates that needs authentication.
 
Now that the login codes have been placed, we need to write it. The user can reuse logs via UI test code, but if the same codes have to be operated before every test, there wouldn’t be much point in having the test, to begin with. Most important, logging in through the UI is slow. If the user has to log in before every test they run, a lot of time will be wasted on logging in. Drupal logs in simply by posting form data to the login URL. 

Seed the data 

It is important to look at how JSON API is used to seed the data which has to be tested and understand that API authenticates the requests. By default (for unsafe and non-read requests) JSON and the standard REST module requires a token request header to be presented. The tokens can then be used to create and delete data by posting the endpoints that are exposed by JSON API module. 

Note that Cypress presents an after hook. It is fascinating to delete the test nodes in the after hook since, at that point, the user has to access to the test node’s id and could delete the test content without having to query by the title. 

However, the approach can be troublesome in the event that needs a test runner to quit or refresh before running the after block. In this case, the test content would never get cleaned up since the user wouldn’t have access to the node’s id in future test runs. Once the test articles are seeded, the “displays published articles” test will visit the node’s page and confirm that the fields
 
Debugging using DevTools

As we can see that Cypress has grown out to be an excellent Test Runner that helps the user to understand what is happening in an application and in the tests, there’s simply no substituting all the amazing work that the browser has done on their built-in development tools.

Your Cypress test code runs in the same run loop as your application. This means you have access to the code running on the page, as well as the things the browser makes available to you, like document, window, and, of course, debugger

Running Cypress in continuous integration

If you want that automated testing and continuous integration should work together then it is important to have some sort of CI/CD server. These are the hosted servers, and for implementing it with Drupal 8 these tools must work together.

It is important to note that developers must ensure that all tests are passed on the local workstation. The Drupal configuration is exported where the system spins up a fresh installation

Conclusion

End-to-end testing shouldn’t be hard. Cypress makes integration testing pleasing and enjoyable. You can write the end to end tests without worrying about browsers, Selenium, and other scary stuff.

You would agree on the fact that the framework is so nice that planning to use nothing but Cypress for integration testing would be fruitful. Plus, the documentation is pure gold: Cypress Docs are filled up with best practices and examples.

At OpenSense Labs, we have quality Drupal experts who try to enable digital transformation to the enterprise with the services and assistance.  Contact us now at [email protected]