Part 4: Understanding the current code structure

Timothy and the product person on the team discuss what would be a good first test to automate. Considering what the users do on the app, they decide that checking the search results would be a good first test.

So they decide that they want to check if the search results are being displayed correctly. They come up with the scenario together.

Let's take a look at the code to understand the structure.

Feature

We have feature files for these plain English scenarios. They are currently inside the tests/features folder:

The search.feature file contains the scenario that Timothy and product person collaborated on. This represents the test

Feature: Search Books

  Scenario: A user should be able to search for books
    When the user searches for a book named "testing"
    Then the search results should display "testing" books

Step Definition

A step definition is a method with an expression that links it to one or more Gherkin steps.

We currently have the step-definitions inside the tests folder:

The step definition in search.steps.ts file links the Gherkin step When the user searches for a book named "testing" as shown below.

import { When } from '@wdio/cucumber-framework';

When(/^the user searches for a book named "(\w+)"$/, async (searchTerm: string) => {
});

(\w+) extracts the word testing from the step and assigns it to the variable searchTerm.

This step currently does not have any code that performs some actions. We will add it shortly.

Similar to the step above, we have the search-results.steps.ts file with a step that links the Gherkin step Then the search results should display "testing" books.

import { Then } from '@wdio/cucumber-framework';

Then(/^the search results should display "(\w+)" books$/, async (expectedTitle: string) => {
});

Here, the variable expectedTitle has the value testing.

Package.json

Package json is a file that stores information about the project like what the project is about, what the dependencies are, the scripts that it supports, etc.

The package.json file is at the root level of the project.

In our repository, package.json file contains scripts as shown below:

It supports test:app:android and test:web:chrome commands. These commands internally call the wdio command and pass configs and platform information.

The android command passes the config specific to tests for android: config/wdio-app-android.conf.ts while the web comand passes a config that is specific to tests for the web: config/wdio-web-chrome.conf.ts

We will see the use of the platform information that is passed to the command later.

Configs

The configs are present in the config folder:

Configs contain all the necessary information to run the test suite.

WebdriverIO documentation about the configuration file can be found here.

In our case, the web config file mentions that the tests need to be run on Chrome browser.

Similarly, the Android config file mentions that the tests need to be run on an Android device.

The shared config contains configurations that are common between web and app. It contains information like which test framework to use, location of feature files, how to generate reports, etc.

Since these configs contain all the information to run the test suite, our test run commands can run the tests on the correct platforms.

Test Run (Current state)

To run the web tests, we run the command:

npm run test:web:chrome

Similarly, when we run the android test run command, the tests run on the Android device.

npm run test:app:android -- --app_path=/Users/lavanya/projects/demo/book-info-e2e-tests/resources/book-info.apk --devices='emulator-5554'

Please update the path to the apk file in the command above.

The test run looks like this:

Do check the readme in the repository if you need to do the setup to get these tests running.

Current code structure

On a high level, the components that we looked at are structured like below in the code:

We have configs that contain the platform specific and shared config files, we have the tests that contain feature files and step definitions and we have package.json file that gives us information about the project.