Logo: Relish

  1. Welcome, Console guest
  2. Sign out

Project: Console

Publisher: WeDeploy

Console

Introduction to WeDeploy Functional Tests

This repository contains functional tests for Console, Admin, wedeploy.com, and WeDeploy Examples. The tests are written using the Cucumber framework. The tests also leverage the Capybara Ruby DSL for driving UI interactions (using Selenium WebDriver).

Features

The test files are grouped by the product's main feature areas, such as accounts, alerts, collaborators, etc. Each group is further subdivided into .feature files. Each .feature file contains one feature and one or more scenarios pertaining to that feature.

Feature: Project Create

Scenario: Project name must be valid
  Given ...
  When ...
  Then ...

Scenario: Create a new project with user input
  Given ...
  When ...
  Then ...

:bulb: Tips:

  • Features are written in a language called Gherkin, which is very close to just plain English.

Scenarios

Each scenario is a self contained test case with its own setup and teardown. The setup occurs in the Given steps. These steps are mostly implemented using api calls. After creating the initial conditions, When steps are performed via the Console UI. These steps mimic user actions for the scenario being tested. Finally, Then steps assert the expected outcome of the user actions.

Example:

Feature: Service Install

Scenario:  Cannot install a service with duplicate ID
    Given I create a project with ID "beta5"
    And I install a "Hosting" service with id "hosting1" for the project "beta5"
    When I click "Services" in the sidebar
    And I click the "Install Service" button
    And I click on the "WeDeploy Hosting" service
    And I enter "hosting1" into the "ID" input field
    And I click the "Install Service" button
    Then I should see the error message
    | The provided service id already exists. |

Steps and Step Definitions

Each scenario is composed of steps. For each step, there must be a matching step definition. While a step is an English-like description of the test step, the step definition is where the test step gets implemented in Ruby.

Example:

Scenario:  Cannot install a service with duplicate ID
    Given I create a project with ID "beta5"

The step definition for the above Given step is found in features/step_defitions/project_steps.rb:

Given("I create a project with ID {string})" do |id|
  project = APIHelper::Project.new(id)
  project.create($tester_email)    # api call to create the project
  @projects_to_delete.push(id)     # save project id for teardown later
  visit("/projects/#{id}/overview")
  expect(page).to have_text(id)
end

Note that a string parameter ("beta5") is passed from the step to the step definition, which is then stored in the local id variable of the step definition.

:bulb: Tips:

  • When adding new steps and step definitions, design the step to maximize reusability. In other words, avoid creating one time use steps as much as possible.

Page Objects

See page objects README.

Test User

Many of the scenarios run in the context of a test user. This test user is created at the beginning of each feature with the 'basic' plan, and the user email is stored in the global variable $tester_email. In any first person step, I is referring to this test user. At the end of the feature, the test user is deleted via the @teardown_tester hook. More on teardowns below.

Teardowns

All data created within a scenario should be deleted at the end of the scenario. This is accomplished with tagged 'after' hooks. Simply tag the scenario with the appropriate cucumber tag. For example, if a scenario creates projects, tag the scenario with @teardown_projects:

@teardown_projects
Scenario:  Invited new user clicks invalid link
    Given I create a project with ID "delta11"
    ...

When the scenario is completed, the after hook for @teardown_projects will run and all projects created in the scenario will be deleted. If the scenario fails in the middle, the after hook still runs and cleans up the projects.

:bulb: Tips:

  • Each scenario can be annotated with as many tags as needed.
  • If the tag is placed at the top of the feature file, then the tag applies to every scenario in that feature.
  • See hooks.rb for the list of available before and after hooks.

Helper Modules

Various helper/utility modules, classes, and methods are available in features/support/helpers.

APIHelper Module

The most notable of these is the APIHelper module. All WeDeploy api calls are made through the classes in this module.

Example:

# Create a test user with email '[email protected]' and update user plan to 'premium'
user = APIHelper::User.new('[email protected]')
user.create('ABC Tester')
user.confirm
user.update_plan('premium')

Topics

  1. Accounts
  2. Admin
  3. Alerts
  4. Collaborators
  5. Common
  6. Deployments
  7. Dxpstack
  8. Examples
  9. Landing page
  10. Login
  11. Pages
  12. Projects
  13. Roles and scopes
  14. Services
  15. Vpn

Last published over 3 years ago by Christie Yoo.