End to End Test vs Component Test

E2E Test

E2E - End to End Tests help verify high value paths in an application. In other words, they help verify user stories as they often represent in the application.

The main purpose of E2E testing is to test from the end user’s experience by simulating the real user scenario and validating the system under test.

Basically these tests check the complete end-to-end process flow - The one happy scenario 

Below are the E2E test cases we can write for the Graph feature

Scenario 1: User can add a Graph

Scenario 2: User can rename the Graph

Scenario 3: User can add data to the Graph

Scenario 4: User can remove the data from the Graph

Scenario 5: User can manage the time zone

Scenario 6: User can delete the Graph

As an example, let’s say we need to write E2E test for Rename Graph scenario. Below is the flow we should cover.

Log in as an Admin → Navigate to the Data Studio → Click on a Dashboard → Click on the graph ellipsis menu → Click on “Rename Graph” → Enter a new name → Click “Done” button → New name should be visible

Blow are the steps we use to write E2E test for above flow

Step 1: Write the test scenario in the configurableDashboard.feature file

Scenario: Admin can rename a graph
        Given "Admin" has navigated to rename graph modal of dashboard "AnotherAdminDashboardForFDS21" created by "AnotherAdmin"
        When User renames a "Graph1" to "Graph2"
        Then User should be able to see the renamed graph "Graph2"

Step 2: Write the steps to perform this scenario in configurableDashboard_steps.js file
        
Given('{string} has navigated to rename graph modal of dashboard {string} created by {string}', (role, dashboardName, author) => {
    ConfigurableDashboardPage.cleanUpDashboardsUsingApi([dashboardName]);
    ConfigurableDashboardPage.createDashboardWithGraphAndDataConfigUsingApi({
        role: author,
        dashboardNames: [dashboardName],
        graphName: 'Graph1',
        createGraph: true,
        createDataConfig: false
    });
    LoginPage.goToUrl('Login');
    LoginPage.login(role);
    ConfigurableDashboardPage.navigateToDashboardManagement();
    ConfigurableDashboardPage.navigateToAConfigDashboard(dashboardName, false);
    ConfigurableDashboardPage.openRenameGraphModal();
});

When('User renames a "Graph1" to {string}', (newGraphName) => {
    ConfigurableDashboardPage.editGraphName(newGraphName);
    ConfigurableDashboardPage.saveNewGraphName();
});

Then('User should be able to see the renamed graph {string}', (newGraphName) => {
    ConfigurableDashboardPage.verifyGraphHasBeenRenamed(newGraphName);
});

Step 3: Write the cypress code for above steps in configurableDashboard_page.js file

static editGraphName(newGraphName) {
  cy.get('input[name="name"]')
    .clear()
    .type(newGraphName);
   };

static saveNewGraphName() {
  cy.get('.add-card-container__buttons-container').get('[data-cy=filledButton]')
    // click function must include `multiple: true` for test to pass in AWS
    .click({ force: true, multiple: true });
  };

static verifyGraphHasBeenRenamed(newGraphName) {
  cy.get('[data-cy=graphName]')
    .contains(newGraphName).eq(0)
    .should('be.visible')
  };

Step 4: Once you done writing E2E test you can run your work in cypress IDE in the Chrome browser. This is what it looks like
        

Component Test

Component Testing is the method where testing of each component in an application is test in separately. The purpose of the component test is to find the defects in the module and verifies the functioning of the piece.

A component is the lowest unit of any application. So, Component testing; as the name suggests, is a technique of testing the lowest or the smallest unit of any application.

In component test, modules or the units are tested independently and you basically validates all the elements of the module such as text, behaver of the buttons, behavior of the text fields, dropdowns etc. against the expected feature.

Below are the component tests we can write for Graph feature

• Add Graph modal

• Add data modal

• Remove data modal

• Rename graph modal

• Manage time zone modal

• Delete graph modal

As an example, let’s say we need to write component test for Rename Graph model. Below is the everything you need to cover in component test.

1. Verify the pop-up text “Rename Graph” is there

2. Verify the “Graph name” text is there

3. Enter a name that has more than 32 characters and how the text field behaves

4. Keep the text field blank and verify the error message

5. Verify the inner text of the text field

6. Enter a name already exist and verify the error message

7. Keep the text field blank and verify the “Done” button is disable

8. Enter a new name and verify the “Done” button is enable

9. Verify clicking on the “Cancel” button would close the pop-up

10. Verify clicking on the “Close” button would close the pop-up

11. Verify clicking outside the pop-up would close the pop-up

As each module has an acceptance criteria, we can priorities component tests based on the value adding to the end product.