Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/noriste/frontend-testing-on-steroids

Front-end Testing on Steroids - companion repo
https://github.com/noriste/frontend-testing-on-steroids

cypress-io testing-javascript

Last synced: 2 months ago
JSON representation

Front-end Testing on Steroids - companion repo

Awesome Lists containing this project

README 

        
# Front-end Testing on Steroids



Why testing a front-end application is so hard? What are the main challenges you need to face? Why do the tests fail without a clear reason?

This talk is about good testing best practices and the tool that is become the de-facto standard of UI Testing: Cypress.



Please note: this is the spoken version of my ["Some UI testing problems and the Cypress way"](https://dev.to/noriste/some-ui-testing-problems-and-the-cypress-way-1167) article.



## Talk walkthrough



### 1 - Cypress works in the browser



There is not an orchestrating Bash script and an orchestrated browser, the tests work directly in the browser.



Topics:



- the Cypress Test List UI: allows easy test selection

- the Cypress Test Runner UI: allows understanding what happens in the app and in Cypress

- everything works in the browser: you do not need to go back and forth from the Bash to the browser

- everything is logged inside the browser' console: you do not need to aggregate logs anymore

- easier command understanding: less tools means more trivial understanding and debugging



Examples:



- logging from the test

- logging from the app

- accessing document.window' properties from the test

- rich assertion results are logged too



### 2 - Everything is async in UI testing



Everything is asynchronous by definition in browserland



Topics:



- there are not sync/async differences, everything is async by definition

- automatic waiting



Examples:



- retrieving and interacting with an element

- asserting about an element visibility



### 3 - Debugging



Debugging is typically hard in E2E testing. Cypress comes to the rescue with a lot of first-class utilities.



Topics:



- tests can be paused and resumed later

- the Cypress Test Runner allows time-travelling: you can analyze the DOM at every test step

- tests have not timeouts, commands have: if something goes wrong, you discover it as soon as possible, without waiting for the while test timeout

- DOM-related errors: when interacting with an element is not possible, Cypress tells you the reason why

- automatic screenshot and videos: in case of failures, watching a video is easier than reading the log



Examples:



- pausing a test programmatically

- time travelling in action

- DOM-related errors with a fixed div all over the contents

- checking failure video



### 4 - UI Integration Tests



E2E Testing is not so important due to its complexity. With full network stubbing, testing only the front-end application is easy and profitable.



Topics:



- full network stubbing

- network error simulation



Examples:



- stubbing the wrong request: how a malformed stub could be detected with Cypress

- stubbing the right request

- happy path testing

- edge case testing



### Productivity



Cypress can be used not only as a development tool but as even as the main development browser.



Topics:



- automating manual interactions while developing

- debugging with Chrome devtools

- installing the React and Redux devtools



### Bonus point



To leverage Cypress' full potential and have stable and useful tests there are a lot of UI Testing best practices.



Topics:



- retrieving elements by their contents: consuming the app the same way the user does is really important in order to have user-centered tests

- AJAX request and response assertions: asserting about AJAX requests alleviates test failure debugging

- clock management: long duration tasks could be fastly tested by controlling browser clock

- running E2E tests just for the happy path: running a limited number of E2E tests saves you a lot of time



Examples:



- full UI Integration tests

- full E2E tests



---



## About this repository



- I bootstrapped this project with [create-react-app](https://facebook.github.io/create-react-app/docs/getting-started)

- it contains a super-simple authentication form

- it contains a fake server with artificial delays to simulate E2E testing slowness

- all the code is well commented, with a lot of links to the slide explanations

- I wrote the front-end app with a outside-in approach writing the acceptance test at the beginning.

  I have not tested it manually at all!



## How to play with it



There are four main commands:



- `npm run start`: starts the (super simple) front-end app and the (fake) back-end app

- `npm run cy:open`: opens the Cypress UI

- `npm test`: launches both the front-end and the back-end apps, and runs cypress in the non-visual

  mode. Remember killing the manually launched apps since it uses the same ports



## How to read it



- launch the front-end app and take a look at the `src/App.js` file

- launch both the back-end app and Cypress

- launch the `authentication.integration.test.js` in Cypress and watch it running

- open the `cypress/integration/authentication.integration.test.js` and explore it

- then, move to the `cypress/integration/authentication.e2e.test.js`

- in the end: run the `npm test` command



## UI Testing Best Practices book



Do not forge to add a star to my (work in progress) [UI Testing Best

Practices](https://github.com/NoriSte/ui-testing-best-practices) book on GitHub 😊