Cypress can test anything that runs in a browser.

This will be a series of articles about cypress from basic to advanced (maybe). If there is something you do not understand, error, do not hesitate to comment.

Login problem

Perhaps one of the first tests that was the hardest was the login screen test.

This screen test is very prone to miss cases since we have to check the correctness of a lot of input from the user. Furthermore, almost every function of a given system always requires user authentication. Therefore, having to perform login in function test files is a prerequisite. So if we write this non-optimal processing, it will slow down functionality testing significantly.

So you can follow these tips.

Completely test the login function in a single run

Since this has always been a very important function in systems, let’s test it out with realism. The most realistic here is to make the most of the user. So when you want to fully test the login or signup function, then test by interacting with the UI (login using UI) exactly the same as the user. For example:

beforeEach() : contains the handles that will always be run before starting the test. Similar to afterEach()

cy.exec() : run system commands, terminal

We see that in the test case there will be the corresponding actions entering the data in the username and password fields. It is easy to see that we are describing the same action the user does.

From there we can write all test cases to fully test this functionality, for example test cases like:

• Invalid username / password
• The account has been locked or deleted
• …

Cypress will have test strategies for common, and popular functions here .

Skip testing on the UI in certain cases

If a function needs to be logged in, then we run the login process again and test, and then test that function, which is considered not optimal and unnecessary. We need to minimize the authentication process because we have tested it completely before. One of the simplest ways here is to avoid doing login operations on the UI, and instead use the API.

Therefore, please note the following 2 things .

When you are writing tests for a particular function, you should test it on the UI.

But when you test a certain function of the system that depends on the state from the above function, you cannot use the UI to set this state.

Let’s see the example login via API using cy.request()

Obviously we save time on login manipulation and testing as it is only the prerequisite of the main function we need to test. Then, just login through the API and operate, test on the main function you need.

Explore more

• Recipes – built-in test strategies for common functions.
• Best Practices – these are hands-on exercises with essential test writing tips.