We are going to implement a test on our app using Cypress; the test signs in and then asks a question. Carry out the following steps to do so:

1. Let's create a new file called qanda.js in the integration folder in the cypress folder with the following content:

describe('Ask question', () => {
  beforeEach(() => {
    cy.visit('/');
  });
  it('When signed in and ask a valid question, the question should successfully save', () => {
    
  });
});

The describe function allows us to group a collection of tests on a feature. The first parameter is the title for the group, while the second parameter is a function that contains the tests in the group.

The it function allows us to define the actual test. The first parameter is the title for the test and the second parameter is a function that contains the steps in the test.

The beforeEach function allows us to define steps to be executed before each test runs. In our case, we are using the visit command to navigate to the root of the app. Remember that the root URL for the app is defined in the baseUrl setting in the cypress.json file.

2.  Let's add the following step in our test:

it('When signed in and ask a valid question, the question should successfully save', () => {
  cy.contains('Q & A');
});

We are checking that the page contains the Q & A text using the contains Cypress command. We can access Cypress commands from the global cy object.

Cypress commands are built to fail if they don't find what they expect to find. Due to this, we don't need to add an assert statement. Neat!

3. Let's give the test a try. We'll need to run our backend in our Visual Studio project. We'll also need to run our frontend by executing npm start in the Terminal. In an additional Terminal window, enter the following to open Cypress:

> npm run cy:open

4. Cypress will detect our test and list it underneath the example tests:

5. Click on the test to execute it:

The test successfully executes and passes. We'll leave the test runner open because it will automatically rerun as we implement and save our test.

6. Let's add the following additional step in our test:

cy.contains('UNANSWERED QUESTIONS');

Here, we are checking that the page contains the correct title. If we save the test and look at the test runner, we'll see that the test has failed:

This is because the title's text isn't actually in capitals – a CSS rule transformed the text into capitals.

Notice the message Cypress uses to inform us of the failing test: Timed out retrying. Cypress will keep trying commands until they pass or a timeout occurs. This behavior is really convenient for us because it allows us to write synchronous style code, even though the operations we are testing are asynchronous. Cypress abstracts this complexity from us. 

7. We'll correct step 6:

cy.contains('Unanswered Questions');

8. Let's add code to go to the sign-in page:

cy.contains('Sign In').click();
cy.url().should('include', 'auth0');

Here, we use the Cypress contains command to locate the Sign In button and chain a click command on this to click the button.

Then, we use the url command to get the browser's URL and chain a should command on this statement to verify that it contains the correct path.

If we look at the test runner, we'll see that the test managed to navigate to Auth0 correctly.

Let's think about these steps that Cypress is executing. The navigation to Auth0 is an asynchronous operation but our test code doesn't appear to be asynchronous. We haven't added a special wait function to wait for the page navigation to complete. Cypress makes testing single-page apps that have asynchronous user interfaces a breeze because it deals with this complexity for us!

9. Next, we'll implement some steps so that we can fill in the sign-in form:

cy.findByLabelText('Email')
  .type('your username')
  .should('have.value', 'your username');

cy.findByLabelText('Password')
  .type('your password')
  .should('have.value', 'your password');

Here, we use the findByLabelText command from the Cypress Testing Library to locate the input. It does this by finding the label containing the text we specified and then finding the associated input (referenced in the label's for attribute). This is another neat function that frees the tests from implementation details such as element IDs and class names.

We chain the Cypress type command so that we can enter characters into the input and then the should command to verify that the input's value property has been set correctly.

10. Let's submit the sign-in form and check that we are taken back to the Q and A app:

cy.get('form').submit();

cy.contains('Unanswered Questions');

We use the Cypress get command to locate the form and then submit it. Then, we check that the page contains the Unanswered Questions text to verify we are back in the Q and A app. Cypress takes care of the asynchronicity of these steps for us.

11. Next, we'll click the Ask a question button to go to the ask page:

cy.contains('Ask a question').click();
cy.contains('Ask a Question');

12. Then, we'll fill in the ask form:

var title = 'title test';
var content = 'Lots and lots and lots and lots and lots of content test';
cy.findByLabelText('Title')
  .type(title)
  .should('have.value', title);
cy.findByLabelText('Content')
  .type(content)
  .should('have.value', content);

We fill in the title and content fields by using the same commands that we did on the sign-in form. The title must be at least 10 characters, and the content must be at least 50 characters, to satisfy the validation rules.

13. Next, we'll submit the question and check that the submission is okay:

cy.contains('Submit Your Question').click();
cy.contains('Your question was successfully submitted');

14. To complete the test, we are going to sign out and check we've been redirected to the correct page:

cy.contains('Sign Out').click();
cy.contains('You successfully signed out!'); 

If we look at the test runner, we'll discover that our test runs and passes successfully:

That completes our end-to-end test and all the tests we are going to create in this chapter. Now that we've written the appropriate unit tests, integration tests, and end-to-end tests, we have a feel for the benefits and challenges of each type, and how to implement them.