Automated Testing Step Reference

This page lists the command steps which can be used in Test Cases.

Table of Contents

Folder, Form and DataPoint References

Many steps require a Folder, Form or DataPoint reference. A Datapoint reference has the format:

FOLDER_OID.FORM_OID.FIELD_OID[RECORD_POSITION]

Folder and Form repeats may also be specified and if not provided Folder and Form repeat are interpreted as 0 so the following are identical:

VISIT[0].VS[0].FIELD_OID[0]
VISIT.VS.FIELD_OID[0]

Note that Field recordposition is always required.

Folder and Form references follow the same pattern but do not include the FIELD_OID section.

Examples of Form references:

VS[0]
VS[1]

Note that Form references and Folder references appear in steps like:

Given Form “VS[0]” exists in Folder “VISIT”

This makes it clear which is a Form reference and which is a Folder reference.

Examples of Folder references:

VISIT[0]
VISIT
CYCLE1/VISIT[0]

Note the third example - Folders may be nested in Rave. Use the / notation to reference the Folder path. See the section on navigating repeated nested folders in the Rave Web Services documentation


Given steps

Given.. steps are used to set up the conditions for a test scenario. At a minimum the test scenario must have some kind of user login and create or select a subject to work with. The When… steps then perform some action which the Then steps check for completion.

Given I am logged in with role “{role}”

Given I am logged in with role "Investigator"

Used at the start of a Scenario, or as part of the Feature Background to log into Medidata Rave with user credentials for a user of this EDC Role type. The credentials (username/password) are provided by the user for the role at execution time along with which Medidata Rave URL, Study and Environment to run the test on.

Given I create a subject

Given I create a subject

Similar to Given a subject exists, this step will create a subject using the name of the Test Case and the date/time that the step was executed if that subject does not already exist. All following actions such as entering data will occur in that Subject.

Given I create a subject named “{subject_name}”

Given I create a subject named "TEST1"

This step will create a subject with the specified name. If an active subject already exists with this name this step will fail. All following actions such as entering data will occur in that Subject.

Given I create a subject named “{subject_name}” at site “{study_site}”

Given I create a subject named "TEST1" at site "LDN01"

This step will create a subject with the specified name in the Site Number specified. If an active subject already exists with this name this step will fail. All following actions such as entering data will occur in that Subject.

Given I create or select the subject named “{subject_name}”

Given I create or select the subject named "TEST1"

Will select an active subject with the given name, or if one does not exist will create it. All following actions such as entering data will occur in that Subject.

Given I create or select the subject named “{subject_name}” at site “{site}”

Given I create or select the subject named "TEST1" at site "LDN01"

Will select an active subject with the given name or if one does not exist will create a subject in the Site Number specified. All following actions such as entering data will occur in that Subject.

Given I fail

Given I fail

This is a special Step definition which can be used in a Given, When or Then step. It stops the execution of the test immediately with a failure message. It can be useful for debugging a test. A test with this step is valid but it will always fail.

Given I inactivate all subjects named “{subject_name}”

Note

This step requires a Medidata Rave Subject Admin user account

Given there are no active subjects named "TEST1"
This step will inactivate any existing subjects with the given subject name

which are in the Project, Environment and Site Number selected for the Test Set Run.

Given I select the subject named “{subject_name}”

Given I select the subject named "TEST1"

This step will find an active subject in Medidata Rave with the given name. Note that a warning will be logged if more than one existing subject with the specified name is found and the most recently created subject will be selected. The step will fail if no active subject exists in Rave with that name. All following actions such as entering data will occur in that Subject.

Given a subject exists

Given a subject exists

This step will create a subject in Medidata Rave. The naming convention for the new Subject is the name of the Test Case and the date/time that the step was executed. All following actions such as entering data will occur in that Subject.

Given folder “{folder}” exists

Note

This step requires a Medidata Rave Subject Admin user account

Given folder "SCREENING" exists

This step ensures that a Folder exists in the current subject with this OID. If the Folder does not exist, it will be created.

Given form “{form}” exists in folder “{folder}”

Note

This step requires a Medidata Rave Subject Admin user account

Given form "PREGNANCY" exists in folder "SCREENING"

This step ensures that a Form exists in the current subject. If the Form does not exist, it will be created.

Given the following data exists

Given the following data exists
      | DataPoint            | Value   |
      | SCREEN.DM.SEX[0]     | Female  |
      | VISIT.VS[1].SYSBP[0] | 121     |
      | VISIT.VS[1].DIABP[0] | 90      |

Identical to the When I enter data step but “Given the following data exists” is a more natural expression in the setup of tests.


When steps

When.. steps are used to perform actions which are then checked by the Then.. steps. You will often see that a step can be performed as a Given.. or as a When… step. You should use the Given.. variant when the step is important to the setup and the When.. to perform the action that is then being tested. i.e. the When.. is what the test is doing to provoke the action to be tested.

When I create a subject

When I create a subject

Similar to Given a subject exists, this step will create a subject using the name of the Test Case and the date/time that the step was executed if that subject does not already exist. All following actions such as entering data will occur in that Subject.

When I create a subject named “{subject_name}”

When I create a subject named "TEST1"

This step will create a subject with the specified name. If an active subject already exists with this name this step will fail. All following actions such as entering data will occur in that Subject.

When I create a subject named “{subject_name}” at site “{study_site}”

When I create a subject named "TEST1" at site "LDN01"

This step will create a subject with the specified name in the Site Number specified. If an active subject already exists with this name this step will fail. All following actions such as entering data will occur in that Subject.

When I create or select the subject named “{subject_name}”

When I create or select the subject named "TEST1"

Will select an active subject with the given name, or if one does not exist will create it. All following actions such as entering data will occur in that Subject.

When I create or select the subject named “{subject_name}” at site “{site}”

When I create or select the subject named "TEST1" at site "LDN01"

Will select an active subject with the given name or if one does not exist will create a subject in the Site Number specified. All following actions such as entering data will occur in that Subject.

When I enter and save data

When I enter and save data
  | DataPoint            | Value | Unit |
  | SCREEN.DM.SEX[0]     | Male  |      |
  | VISIT[2].VS.SYSBP[0] | 149   | mmHG |

Enter data for DataPoints in the current Subject. A Subject must have been created before this step can be performed or it will fail with an error.

This step will perform an overall Save action for each Form in the data table, see saving forms

The step requires a data table to follow it with columns for DataPoint and Value. An optional Unit column may also be provided if the Datapoints being entered make use of a UnitDictionary. The Unit values provided should be the User Data String values (i.e. what the user sees, not the coded value). If the Unit Value is Fixed in Rave then it should not be provided.

Values for CheckBoxes should be 1 (Checked) or 0 (Unchecked). Values for Dates should be entered in the format DD MMM YYYY e.g. 02 JAN 2018 Values for Time should be entered in the format hh:mm:ss e.g. 14:23:01 Values for Datapoints with Data Dictionaries should use the User Data String (i.e. what the user sees, not the coded value) Values may be entered which are non-conformant. e.g. for a Numeric field a value of “a” could be entered.

Note

This step enters the data as if you had entered the data via the Rave interface. It submits empty values for all the other Datapoints on the page unless you enter values for them also. See When I enter only this data step for a version that does not enter these empty values.

Note

This step will enter data into Datapoints which are active but not visible.

Note

This step will wait up to 60 seconds for the form to be saved in Rave. If Rave takes longer than 60 seconds, because of Custom Functions for example, this step will fail. If the Custom Function(s) cannot be optimized you can run the Test Case using the ‘Continue on Failure’ option.

When I enter data

When I enter data
  | DataPoint            | Value | Unit |
  | SCREEN.DM.SEX[0]     | Male  |      |
  | VISIT[2].VS.SYSBP[0] | 149   | mmHG |

Enter data for DataPoints in the current Subject. A Subject must have been created before this step can be performed or it will fail with an error.

The step requires a data table to follow it with columns for DataPoint and Value. An optional Unit column may also be provided if the Datapoints being entered make use of a UnitDictionary. The Unit values provided should be the User Data String values (i.e. what the user sees, not the coded value). If the Unit Value is Fixed in Rave then it should not be provided.

Values for CheckBoxes should be 1 (Checked) or 0 (Unchecked). Values for Dates should be entered in the format DD MMM YYYY e.g. 02 JAN 2018 Values for Time should be entered in the format hh:mm:ss e.g. 14:23:01 Values for Datapoints with Data Dictionaries should use the User Data String (i.e. what the user sees, not the coded value) Values may be entered which are non-conformant. e.g. for a Numeric field a value of “a” could be entered.

Note

This step enters the data as if you had entered the data via the Rave interface. It submits empty values for all the other Datapoints on the page unless you enter values for them also, with the exception of Derived Fields, see saving forms and I enter and save data. See When I enter only this data step for a version that does not enter these empty values.

Note

This step will enter data into Datapoints which are active but not visible.

When I enter no data

When I enter no data

A step which does nothing. This step exists to document that no data is being entered into Rave.

When I enter only this data

When I enter only this data
      | DataPoint             | Value       |
      | UNSCHEDULED.VS.DTC[0] | 01 Dec 2019 |

Enter data for only specific DataPoints in the current Subject. A Subject must have been created before this step can be performed or it will fail with an error.

The step requires a data table to follow it with columns for DataPoint and Value. An optional Unit column may also be provided if the Datapoints being entered make use of a UnitDictionary. The Unit values provided should be the User Data String values (i.e. what the user sees, not the coded value). If the Unit Value is Fixed in Rave then it should not be provided.

Values for CheckBoxes should be 1 (Checked) or 0 (Unchecked). Values for Dates should be entered in the format DD MMM YYYY e.g. 02 JAN 2018 Values for Time should be entered in the format hh:mm:ss e.g. 14:23:01 Values for Datapoints with Data Dictionaries should use the User Data String (i.e. what the user sees, not the coded value) Values may be entered which are non-conformant. e.g. for a Numeric field a value of “a” could be entered.

Note

This step enters data only for the Datapoints referenced. This mimicks the behaviour of entering data via Rave Web Services as a data integration might. It does not enter empty values for other Datapoints on the same Form - which is what would happen if you were entering the data via Medidata Rave as a user. See the When I enter data step for a version which enters empty values just like a user.

Note

This step will enter data into Datapoints which are active but not visible.

When I fail

When I fail

This is a special Step definition which can be used in a Given, When or Then step. It stops the execution of the test immediately with a failure message. It can be useful for debugging a test. A test with this step is valid but it will always fail.

When I inactivate all subjects named “{subject_name}”

Note

This step requires a Medidata Rave Subject Admin user account

When there are no active subjects named "TEST1"
This step will inactivate any existing subjects with the given subject name

which are in the Project, Environment and Site Number selected for the Test Set Run.

When I inactivate folder “{folder}”

Note

This step requires a Medidata Rave Subject Admin user account

When I inactivate folder "UNSCHEDULED[1]"

This step will inactivate a Folder.

When I inactivate form “{form}” in folder “{folder}”

Note

This step requires a Medidata Rave Subject Admin user account

When I inactivate form "VISIT" in folder "UNSCHEDULED[1]"

This step will inactivate a Form.

When I inactivate record “{record_position}” in form “{form}” in folder “{folder}”

When I inactivate record 1 in form "VISIT" in folder "UNSCHEDULED[1]"

This step will inactivate a Log Record.

When I log in with role “{role}”

When I log in with role "Data Manager"

Similar to the Given I am logged in with role “{role}” step but can be used in a Scenario where you want to set up a test using one user type and then change to another user type in order to check results. For example you might enter data using an Investigator or CRC user Role and then log in as a user with a Data Manager Role to check that a Query has been opened to the Data Manager. You would not be able to see that Query with an Investigator user since they do not have permissions on that Marking group.

When I save form “{form}” in folder “{folder}”

When I save form "PREGNANCY" in folder "SCREENING"

This step ensures that a Form has been saved as it would be in Rave by clicking on the ‘Save’ button. If there are Edit Checks triggered by a ‘NOW’ Derivation they will not be triggered by other Enter Data test steps, so this step should be used to ensure that the expected actions on the page occur.

Note

This step will wait up to 60 seconds for the form to be saved in Rave. If Rave takes longer than 60 seconds, because of Custom Functions for example, this step will fail. If the Custom Function(s) cannot be optimized you can run the Test Case using the ‘Continue on Failure’ option.

When I select the subject named “{subject_name}”

When I select the subject named "TEST1"

This step will find an active subject in Medidata Rave with the given name. Note that a warning will be logged if more than one existing subject with the specified name is found and the most recently created subject will be selected. The step will fail if no active subject exists in Rave with that name. All following actions such as entering data will occur in that Subject.


Then steps

Then.. steps are used to verify actions which When.. steps have set in motion. For example, a Then.. step is typically used to check that an Edit Check has created (or not created) a Query based on data entry performed in a When.. step.

Then I fail

Then I fail

This is a special Step definition which can be used in a Given, When or Then step. It stops the execution of the test immediately with a failure message. It can be useful for debugging a test. A test with this step is valid but it will always fail.

Then I should not see a folder “{folder}” with name “{folder_name}”

Then I should not see a "UNSCHED" folder with name "Unscheduled (1)"

This step tests for the absence of a Folder identified by a Folder OID with a set name. Useful for checking that SetFolderName actions have executed correctly.

Then I should not see a form “{form}” in folder “{folder}” with name “{form_name}”

Then I should not see a "SAE" form in folder "SAES" with name "SAE (1)"

This step checks that a Form identified by the Form OID provided exists in a Folder identified by a Folder OID but does not have the provided Form name

Then I should not see field “{datapoint}”

Then I should not see field "SCREEN.DM.CHILDBEARING"

This step is the opposite of the Then I should see field “{datapoint}” step. It checks that a Field IS NOT visible on the Form. Useful for testing Edit Checks which use the SetFieldVisible check action

Then I should not see fields

Then I should not see fields
    | Field                  |
    | SCREENING.DH.DISEASE1  |
    | SCREENING.DH.DISEASE2  |
    | SCREENING.DH.DISEASE3  |
    | SCREENING.DH.DISEASE4  |

This step checks that the listed Fields DO NOT appear on the Form. It is the opposite of the Then I should see fields step.

Then I should not see form “{form}” in folder “{folder}”

Then I should not see form "VISIT" in folder "UNSCHEDULED[1]"

The opposite of Then I should see form “{form}” in folder “{folder}”, this step tests that a Form cannot be seen in this Folder by this user. It will fail if the Form can be seen.

Then I should not see queries on “{datapoint}”

I should not see queries on "SCREEN.VISIT.VDATE[0]"

This step checks whether the Datapoint referenced has ANY queries and fails if it has any. It can be used where the text of the query to be checked is dynamic (e.g. set by a Custom Function). If any Queries are found on the Datapoint then the step fails and a list of the Query messages found is provided.

Then I should not see the following comment on “{datapoint}”

Then I should not see the following comment on "VISIT[1].VS.AE_YN"
    """
    Record all Adverse Events in the Common Adverse Event Folder
    """

The reverse of the Then I should see the following comment on “{datapoint}” step. This step checks that a comment DOES NOT exist on a DataPoint. The step will fail if it finds the exact text provided in a comment on the Datapoint.

Then I should not see the following query on “{datapoint}”

Then I should not see the following query on "SCREEN.VS.SYSBP[0]"
  """
  Patients SYSBP is too high. Please clarify
  """

The reverse of Then I should see the following query on “{datapoint}”’. This step checks that a query DOES NOT exist on a particular Datapoint. If the exact Query Text provided appears on that Datapoint then the step will fail.

Then I should not see the following sticky on “{datapoint}”

Then I should not see the following sticky on "BASELN.DM.PTEST[0]"
    """
    Please remember to mail urine sample to the central testing facility.
    """

The reverse of Then I should see the following sticky on “{datapoint}”. This step checks that a sticky HAS NOT been placed on a Datapoint. The step will fail if the sticky is found on the Datapoint.

Then I should see “{datapoint}” does not have value “{value}”

Then I should see "SUBJECT.AE.SERIOUS" does not have value "1"

The opposite of the Then I should see “{datapoint} has value “{value}” step. This steps checks that the Datapoint referenced DOES NOT have the value provided.

Then I should see “{datapoint}” has value “”

Then I should see "SUBJECT.AE.SERIOUS" has value ""

This step checks that the Datapoint referenced has an empty value and fails if it does not.

Then I should see “{datapoint}” has value “{value}”

Then I should see "SUBJECT.AE.SERIOUS" has value "0"

This step checks that the Datapoint referenced has the value provided and fails if it does not.

Then I should see “{datapoint}” is empty

Then I should see "SUBJECT.AE.SERIOUS" is empty

This step checks that the Datapoint referenced has an empty value and fails if it does not.

Then I should see a folder “{folder}” with name “{folder_name}”

Then I should see a "UNSCHED" folder with name "Unscheduled (1)"

This step tests for the existence of a Folder with a set name. Useful for checking that SetFolderName actions have executed correctly.

Then I should see a form “{form}” in folder “{folder}” with name “{form_name}”

Then I should see a "SAE" form in folder "SAES" with name "SAE (1)"

This step checks that a Form exists in a Folder with the provided Form name

Then I should see data

Then I should see data
    | DataPoint            | Value | Unit |
    | SCREEN.DM.SEX[0]     | Male  |      |
    | VISIT[2].VS.SYSBP[0] | 149   | mmHG |

This step verifies that data has been entered into Rave. It can check multiple Forms in Rave in a single statement and will take a screenshot of each Rave web page as evidence. Similar to the When I enter data step, it requires a table of Datapoint references with Value and optional unit if data requires a Unit Dictionary.

Values for CheckBoxes should be 1 (Checked) or 0 (Unchecked). Values for Dates should be entered in the format DD MMM YYYY e.g. 02 JAN 2018 Values for Time should be entered in the format hh:mm:ss e.g. 14:23:01 Values for Datapoints with Data Dictionaries should use the User Data String (i.e. what the user sees, not the coded value) Values may be entered which are non-conformant. e.g. for a Numeric field a value of “a” could be entered.

Then I should see data statuses

Then I should see data statuses
  | DataPoint            | Status   |
  | BASELN.DM.HEIGHT[0]  | frozen   |
  | BASELN.VS.WEIGHT[0]  | frozen   |
  | BASELN.VS.SYSBP[0]   | locked   |

Verifies that the list of Datapoints referenced have the data status expected. Possible data statuses are:

  • locked

  • unlocked

  • frozen

  • unfrozen

  • verified

  • verificationrequired

  • nothingtoverify

Then I should see field “{datapoint}”

Then I should see field "SCREEN.DM.CHILDBEARING"

This step checks that a Field is visible on the Form. Useful for testing Edit Checks which use the SetFieldVisible check action. If you wish to check multiple Fields in a test then it may be better to use Then I should see fields to provided a table of Fields to check

Then I should see fields

Then I should see fields
        | Field                  |
        | SCREENING.DH.DISEASE1  |
        | SCREENING.DH.DISEASE2  |
        | SCREENING.DH.DISEASE3  |
        | SCREENING.DH.DISEASE4  |

This step checks that the listed Fields appear on the Form. It is useful when you hide or show a set of Fields via the Edit Check SetDatapointVisible Check Action or you hide/show Fields via a Custom Function.

Then I should see form “{form}” in folder “{folder}”

Then I should see form "VISIT" in folder "UNSCHEDULED[1]"

This step tests to see if a Form can be seen by this user in the current Subject. It will fail if the Form does not exist or if the user cannot see it due to View restrictions.

Then I should see subject calendar

Then I should see subject calendar
    | Visit    | Date          |
    | V1       | 01 AUG 2018   |
    | UNS[1]   | 10 SEP 2018   |
    | UNS[2]   | 13 SEP 2018   |
    | V2       | 06 DEC 2018   |

This step checks the values of the Subject Calendar dates for Visits. Visits are identified by Folder OID and repeat number (optional). Dates are formatted DD MMM YYYY

Then I should see subject name is “{subject_name}”

Then I should see subject name is "LP901"

This step checks that the subject name matches the value provided. Useful for checking Edit Checks which use the SetSubjectName action

Then I should see subject name is not “{subject_name}”

Then I should see subject name is not "XR103"

The reverse of the Then I should see subject name is “{subject_name}” step. This step checks that the subject name DOES NOT match the value provided. Useful for checking Edit Checks which use the SetSubjectName action.

Then I should see subject status is “{subject_status}”

Then I should see subject status is "Randomized"

This step checks the Subject Status. Useful for testing Edit Checks which use the SetSubjectStatus Check Action. The Subject Status should match a value that can be set in the Core Configuration of the study you are testing.

Then I should see subject status is not “{subject_status}”

Then I should see subject status is not "Randomized"

The reverse of the Then I should see subject status is “{subject_status}” step. This step checks that the subject status DOES NOT match the value provided. Useful for checking Edit Checks which use the SetSubjectStatus action.

Then I should see that “{datapoint}” is conformant

Then I should see that "SUBJECT.AE.AE_NUM[0]" is conformant

This step checks that a Datapoint is conformant (has no non-conformance error message)

Then I should see that “{datapoint}” is non-conformant

Then I should see that "SUBJECT.AE.AE_NUM[0]" is non-conformant

This step checks that a Datapoint is marked as non conformant.

Then I should see that “{datapoint}” is not submitted

Then I should see that "SUBJECT.AE.AE_NUM[0]" is not submitted

This step checks that a Datapoint has not been submitted, i.e. there is not audit trail record in Rave

Then I should see that “{datapoint}” is submitted

Then I should see that "SUBJECT.AE.AE_NUM[0]" is submitted

This step checks that a Datapoint has been submitted, i.e. there is an audit trail record in Rave

Then I should see the following comment on “{datapoint}”

Then I should see the following comment on "VISIT[1].VS.AE_YN"
    """
    Record all Adverse Events in the Common Adverse Event Folder
    """

This step checks that a comment exists on a DataPoint. The step checks for the exact text of the comment and fails if it is not found.

Then I should see the following query on “{datapoint}”

Then I should see the following query on "SCREEN.VS.SYSBP[0]"
  """
  Patients SYSBP is too high. Please clarify
  """

This step checks that a query exists on a particular Datapoint. If the exact Query Text provided does not appear on that Datapoint then the step will fail.

Then I should see the following sticky on “{datapoint}”

Then I should see the following sticky on "BASELN.DM.PTEST[0]"
    """
    Please remember to mail urine sample to the central testing facility.
    """

This step checks that a sticky has been placed on a Datapoint. The step will fail if the sticky cannot be found.

Then the Dynamic Search List for “{datapoint}” should contain the following values

Then the Dynamic Search List for "SUBJECT.WD.AE" should contain the following values:
    | Value             | Code           |
    | Nausea            | 001            |
    | Rash              | 002            |
    | Migraine Headache | 003            |

This step checks the values available in a Dynamic Search List. Note that a screenshot will not be taken but the values will be verified and confirmed. The value and code of the DSL are verified.

Then the Dynamic Search List for “{datapoint}” should not contain the following values

Then the Dynamic Search List for "SUBJECT.WD.AE" should not contain the following values:
    | Value             | Code           |
    | Nausea            | 001            |
    | Rash              | 002            |
    | Migraine Headache | 003            |

This step checks that values are not in a Dynamic Search List. Note that a screenshot will not be taken but the absence of the values and associated codes will be verified and confirmed.