Cypress – how to help you improve your relationship with QA

Tram Ho

Up to now, in many projects, there has always been an underground link between developers and QA. Why? There is a brother who once told me, dev mindset is to develop and improve the system, and QA will be to destroy the system. Well, don’t understand here that they want the project to fail but they want the perfect product before it reaches the user. In general, developers and QA are responsible and love their products, just that each side loves it in their own way. And QA also has extremely hard times. When you have to test a monitor with a ton of functions, big and small in it, and one fine day, a little bit changes, and you have to test the whole screen again. Not to mention breaking changes that resulted in the need to re-test n different screens. Thinking here is also depressing, right? For a while, the focus is today I want to introduce you to a test tool called cypress. In my opinion, cypress is basically a user that we pre-program our actions and have super fast operation speed. With the difficulties I mentioned above, cypress will help you overcome, it will reduce re-test functionality. You can find out details on the cypress homepage

Advantages :

  • Cypress can help you perform many types of tests such as: End-to-end test, Integration test, Unit test.
  • The way to install and use is quite simple
  • Can run on many types of browsers
  • Debug is easy right during test run ( details )

Defect

  • The run time is quite long
  • Consuming the resources of the server, if running the whole system, it can lead to full ram, full CPU, making the services on the server unusable (so testing env and production env on a server then running cypress will quite wrong)

Request

To run cypress, you need to meet the following conditions

  • Operating system: MacOS> = 10.9 (64bit), Linux Ubuntu> = 12.04, Fedora 21 and Debian8 (64 bit), Window> = 7
  • NodeJS> = 10, if the version is in the low Nodejs version and cannot be upgraded because there is an old package that cannot run on a higher node, you can download the old cypress version.
  • The project’s spec and requirement must be complete and detailed

Setting

Move into the project directory

Npm:

Yarn:

Or you can download directly here

Run Cypress

After installing cypress, you will see a cypress folder is created and cypress.json file (containing config) is created.

A brief explanation of the directory structure:

  • fixtues : This is the folder containing static data to use during test run.
  • integration : The folder contains the test file. Test file can be file format: .js , .jsx , .coffee , .cjsx .
  • plugins : For each time the spec file is run, the plugins in plugins/index.js will be run. You will not have to import all of your spec test files
  • support : About the way it runs, it is also plugins, but the purpose of use is different. The support files will contain repetitive operations such as commands.

Those are the default folders that cypress generate for us, if you don’t like them, you can edit them in the config

To run cypress you can do one of the following

Runs directly from node_modules:

npm bin

npx

yarn

Or in package.json you can add a script

By default, cypress will have a sample file for you to test, of course it will not test anything: v

Let’s write some tests

As I said above, it requires full spec and requirement. Because if not, what criteria will you base on to test, right? And when there are enough requirements, the next step is not to write code but will be to build test cases – a job not very familiar to developers, right. At this time, we have to run to QA for back shoulder massage to ask for a test case or ask just to write the test case by ourselves.

After you have enough, but the above is the code. I want to use code in my project more, but for security reasons, I will use the temporary code on the cypress homepage. You can use the following command to generate the test file:

Here, I am asking cypress to check the access via the https://example.cypress.io link

Now I will check to see if there is a Querying string

And this is the result:

Try changing it back to Queries to get an error

But myself, I will not like this contains very much, contains will only check if there exists a string or element you pass in or not, but if I want to check correctly, I will use the following:

As you can see it has checked correctly that in the segment I want the string is Querying . But of course writing this way wouldn’t be fine. First, it’s too long. The second is that we are querying for things like class names, tags – those are the things that are prone to change. So what is the advice here is, let’s add an attribute for the things we have to test, for example in the other code on the cypress page is like this:

Then change the bar like this:

At this point, our command will be just:

Try adding a click on the element we get

Try it and see the results

About actions, you can read here: https://example.cypress.io/

Also above you find yourself using should – it’s an assertion, you can read it here: https://docs.cypress.io/guides/references/assertions.html#BDD-Assertions

My post today only came here, not everything, so please remember to read more docs.

Link docs: https://docs.cypress.io/guides/overview/why-cypress.html

And remember to read Best practices too: https://docs.cypress.io/guides/references/best-practices.html

Share the news now

Source : Viblo