To add a collaborator to this project you will need to use the Relish gem to add the collaborator via a terminal command. Soon you'll be able to also add collaborators here!
More about adding a collaboratorConsole
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
- Accounts
- Admin
- Alerts
- Collaborators
- Common
- Deployments
- Dxpstack
- Examples
- Landing page
- Login
- Pages
- Projects
- Roles and scopes
- Services
- Vpn
Last published over 3 years ago by Christie Yoo.