Automated Testing Step Reference

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

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 activate record "{record_position}" in form "{form}" in folder "{folder}"

Given I activate record "1" in form "VISIT" in folder "UNSCHEDULED[1]"

This step will activate a Log Record. If the Log Record is already active then this step will fail.

Given I add event "{matrix}"

Note

This step requires version 7 or higher of the TG_UAT draft.

Given I add event "SCREENING"

This step performs a Rave 'Add Event' action, i.e. adding a Matrix to the test subject. The Matrix must be set to be Addable.

Given I add folder "{folder_oid}" to folder "{folder}"

Note

This step requires version 8 or higher of the TG_UAT draft.

Given I add folder "VISIT" to folder "UNSCH"

This step adds a Folder within another Folder. See also I add folder to the subject

Note

If the same Folder already exists inside the parent Folder then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a folder exists.

Given I add folder "{folder_oid}" to the subject 

Note

This step requires version 8 or higher of the TG_UAT draft.

Given I add folder "VISIT" to the subject

This step adds a Folder at the Subject level. See also I add folder to folder

Note

If the same Folder already exists at the Subject level then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a folder exists.

Given I add form "{form_oid}" to folder "{folder}"

Note

This step requires version 8 or higher of the TG_UAT draft.

Given I add form "VISIT" to folder "UNSCH"

This step adds a Form within a Folder instance. See also I add form to the subject

Note

If the same Form already exists within the parent Folder then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a form exists.

Given I add form "{form_oid}" to the subject 

Note

This step requires version 8 or higher of the TG_UAT draft.

Given I add form "VISIT" to the subject

This step adds a Form at the Subject level. See also I add form to folder

Note

If the same Form already exists at the Subject level then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a form exists.

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 assign {lab_type} lab "{lab_name}" to form "{form}" in folder "{folder}"

Given I assign Central lab "TG_LABS" to form "PREGNANCY" in folder "SCREENING"

This step assigns a Rave Central or Local Lab to a form. If the Lab Name contains a double quote character you should prefix it with a backslash: I assign Central lab "TG\"S LAB" to form "PREGNANCY" in folder "SCREENING"

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 

Note

This step requires a Medidata Rave Subject Admin user account

Given I inactivate all subjects

This step will inactivate ALL existing subjects which are in the Project, Environment and Site Number selected for the Test Set Run.

Note

This step cannot be run against a production Rave environment.

Given I inactivate all subjects at site "{study_site}"

Note

This step requires a Medidata Rave Subject Admin user account

Given I inactivate all subjects at site "LDN01"

This step will inactivate ALL existing subjects which are in the Project, Environment selected for the Test Set Run and the Site Number specified in the step.

Note

This step cannot be run against a production Rave environment.

Given I inactivate all subjects named "{subject_name}"

Note

This step requires a Medidata Rave Subject Admin user account

Given I inactivate all 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 inactivate all subjects named "{subject_name}" at site "{study_site}"

Note

This step requires a Medidata Rave Subject Admin user account

Given I inactivate all subjects named "TEST1" at site "LDN01"

This step will inactivate any existing subjects with the given subject name which are in the Project, Environment selected for the Test Set Run and the Site Number specified in the step.

Given I inactivate record "{record_position}" in form "{form}" in folder "{folder}"

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

This step will inactivate a Log Record. If the Log Record is already inactive then this step will fail.

Given I open URL "{url}"

Given I open URL "https://www.trialgrid.io"

Opens the specified URL in the browser which is running the Test Case. The URL should start with a valid HTTP protocol, e.g. https:// or http://

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 I take screenshots with Rave EDC role "{edc_role}"

Note

This step requires version 7 or higher of the TG_UAT draft.

Given I take screenshots with Rave EDC role "Data Manager"

This step will change the user role in Rave EDC. If a user account has multiple roles in Rave EDC then a specific role can be selected for taking screenshots.

If the user account has only one role, or the role is not important, then this step is not required.

This step is not required for testing against Rave Classic.

Given I use a page size of {page_size} records 

Given I use a page size of 10 records

This is a special Step definition which can be used in a Given or When step. It sets the 'per page' setting on each page visited. This step should only be used when testing Rave EDC and is mainly for use in testing TrialGrid.

Given I wait {seconds} seconds 

Given I wait for 10 seconds

This is a special Step definition which can be used in a Given or When 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 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. If the Folder has a Parent Folder then we recommend using I add folder to the subject or I add folder to folder

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 activate record "{record_position}" in form "{form}" in folder "{folder}"

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

This step will activate a Log Record. If the Log Record is already active then this step will fail.

When I add event "{matrix}"

Note

This step requires version 7 or higher of the TG_UAT draft.

When I add event "SCREENING"

This step performs a Rave 'Add Event' action, i.e. adding a Matrix to the test subject. The Matrix must be set to be Addable.

When I add folder "{folder_oid}" to folder "{folder}"

Note

This step requires version 8 or higher of the TG_UAT draft.

When I add folder "VISIT" to folder "UNSCH"

This step adds a Folder within another Folder. See also I add folder to the subject

Note

If the same Folder already exists inside the parent Folder then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a folder exists.

When I add folder "{folder_oid}" to the subject 

Note

This step requires version 8 or higher of the TG_UAT draft.

When I add folder "VISIT" to the subject

This step adds a Folder at the Subject level. See also I add folder to folder

Note

If the same Folder already exists at the Subject level then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a folder exists.

When I add form "{form_oid}" to folder "{folder}"

Note

This step requires version 8 or higher of the TG_UAT draft.

When I add form "VISIT" to folder "UNSCH"

This step adds a Form within a Folder instance. See also I add form to the subject

Note

If the same Form already exists within the parent Folder then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a form exists.

When I add form "{form_oid}" to the subject 

Note

This step requires version 8 or higher of the TG_UAT draft.

When I add form "VISIT" to the subject

This step adds a Form at the Subject level. See also I add form to folder

Note

If the same Form already exists at the Subject level then a new one will be created.

Note

This step does not require Rave subject administration permission unlike Test Step a form exists.

When I assign {lab_type} lab "{lab_name}" to form "{form}" in folder "{folder}"

When I assign Central lab "TG_LABS" to form "PREGNANCY" in folder "SCREENING"

This step assigns a Rave Central or Local Lab to a form. If the Lab Name contains a double quote character you should prefix it with a backslash: I assign Central lab "TG\"S LAB" to form "PREGNANCY" in folder "SCREENING"

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 and save data on active fields 

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

This step is a variation of enter and save data.

Data will not be entered on Fields which are inactive or Fields which are on inactive Forms or on Fields which do not exist in the Draft.

When I enter and save data on active forms and fields 

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

This step is a variation of enter and save data.

Data will not be entered on Fields which are inactive or Fields which are on inactive Forms or on Fields which do not exist in the Draft.

Before entering data, TrialGrid will check the subject in Rave and if the Form does not exist in the specified Folder then TrialGrid will not try to enter data onto that Form.

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. Values for Dynamic Search Lists can include valid, non-conformant and empty values. The DSL specific step "{datapoint}" <when_i_select_value_value_from_the_dynamic_search_list_on_datapoint>` can also be used, and will fail if the value is not in the DSL.

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 

Note

This step requires a Medidata Rave Subject Admin user account

When I inactivate all subjects

This step will inactivate ALL existing subjects which are in the Project, Environment and Site Number selected for the Test Set Run.

Note

This step cannot be run against a production Rave environment.

When I inactivate all subjects at site "{study_site}"

Note

This step requires a Medidata Rave Subject Admin user account

When I inactivate all subjects at site "LDN01"

This step will inactivate ALL existing subjects which are in the Project, Environment selected for the Test Set Run and the Site Number specified in the step.

Note

This step cannot be run against a production Rave environment.

When I inactivate all subjects named "{subject_name}"

Note

This step requires a Medidata Rave Subject Admin user account

When I inactivate all 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 all subjects named "{subject_name}" at site "{study_site}"

Note

This step requires a Medidata Rave Subject Admin user account

When I inactivate all subjects named "TEST1" at site "LDN01"

This step will inactivate any existing subjects with the given subject name which are in the Project, Environment selected for the Test Set Run and the Site Number specified in the step.

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. If the Log Record is already inactive then this step will fail.

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 open URL "{url}"

When I open URL "https://www.trialgrid.io"

Opens the specified URL in the browser which is running the Test Case. The URL should start with a valid HTTP protocol, e.g. https:// or http://

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.

When I select value "{value}" from the Dynamic Search List on "{datapoint}"

Note

This step requires version 7 or higher of the TG_UAT draft.

When I select value "ONE" from the Dynamic Search List on "SUBJECT.AE.AETERM[0]

Enter data by selecting a value from the Dynamic Search List. If the value does not exist in the DSL then this step will fail. Non-conformant DSL values which do not exist in the list can be entered with Enter Data steps. Values are case-insensitive, e.g. 'ONE' is the same as 'one'.

When I take screenshots with Rave EDC role "{edc_role}"

Note

This step requires version 7 or higher of the TG_UAT draft.

When I take screenshots with Rave EDC role "Data Manager"

This step will change the user role in Rave EDC. If a user account has multiple roles in Rave EDC then a specific role can be selected for taking screenshots.

If the user account has only one role, or the role is not important, then this step is not required.

This step is not required for testing against Rave Classic.

When I use a page size of {page_size} records 

When I use a page size of 10 records

This is a special Step definition which can be used in a Given or When step. It sets the 'per page' setting on each page visited. This step should only be used when testing Rave EDC and is mainly for use in testing TrialGrid.

When I wait {seconds} seconds 

When I wait for 10 seconds

This is a special Step definition which can be used in a Given or When 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 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 deviation on "{datapoint}" with code "{code}" and class "{class}" and message 

Note

This step requires version 9 or higher of the TG_UAT draft.

Then I should not see a deviation "SCREEN.VS.SYSBP[0]" with code "Finding" and class "Procedure deviation" and message
    """
    COVID-19 pandemic related
    """

This step checks that a protocol deviation does not exist on a particular Datapoint.

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 an answered query on "{datapoint}"

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

This step checks that an answered query does not exist on a particular Datapoint.

Then I should not see an open query on "{datapoint}"

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

This step checks that an open query does not exist on a particular Datapoint.

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.

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 an open query DOES NOT exist on a particular Datapoint.

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 text 

Then I should see "SUBJECT.AE.SERIOUS" does not have text
"""
The subject had
a serious
event
"""

The opposite of the Then I should see "{datapoint}" has text step. This steps checks that the Datapoint referenced DOES NOT have the text provided. The text should be provided as a multi-line string. If multiple lines are not required then this step should be used Then I should see "{datapoint}" does not have value.

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. If the value is on multiple lines then this step should be used: Then I should see "{datapoint}" has text.

Then I should see "{datapoint}" has text 

Then I should see "SUBJECT.AE.SERIOUS" has text
"""
The subject had
a serious
event
"""

This step checks that the Datapoint referenced has the text provided and fails if it does not. The text should be provided as a multi-line string. If multiple lines are not required then this step should be used Then I should see "{datapoint}" has value.

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. If the value is on multiple lines then this step should be used: Then I should see "{datapoint}" has text.

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 deviation on "{datapoint}" with code "{code}" and class "{class}" and message 

Note

This step requires version 9 or higher of the TG_UAT draft.

Then I should see a deviation "SCREEN.VS.SYSBP[0]" with code "Finding" and class "Procedure deviation" and message
    """
    COVID-19 pandemic related
    """

This step checks that a Protocol Deviation exists on a particular Datapoint.

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 an answered query on "{datapoint}"

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

This step checks that an answered query exists on a particular Datapoint.

Then I should see an open query on "{datapoint}"

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

This step checks that an open query exists on a particular Datapoint.

Then I should see data 

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

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.

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 lab ranges 

Note

This step requires version 10 or higher of the TG_UAT draft.

Then I should see lab ranges
  | DataPoint         | Range Status   | Range Low | Range High | Lab Numeric Value |
  | BASELN.LB.WBC[0]  | High           | 4000      | 11000      | 12000             |
  | BASELN.LB.RBC[0]  | Normal         | 4.5       | 5.9        | 4.6               |

Verifies that the list of Datapoints referenced have the lab ranges expected. The DataPoint column is required, other columns are optional.

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 that record "{record_position}" in form "{form}" in folder "{folder}" is active 

Note

This step requires version 7 or higher of the TG_UAT draft.

Then I should see that record "1" in form "VISIT" in folder "UNSCHEDULED[1]" is active

This step will verify that a record is active.: This step can be used with log or standard records.

Then I should see that record "{record_position}" in form "{form}" in folder "{folder}" is inactive 

Note

This step requires version 7 or higher of the TG_UAT draft.

Then I should see that record "1" in form "VISIT" in folder "UNSCHEDULED[1]" is inactive

This step will verify that a record is inactive.: This step can be used with log or standard records.

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.

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 an open query exists on a particular Datapoint.

Then I should see the following query on "{datapoint}" [multiple allowed]

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

This step checks that a query exists on a particular Datapoint.: If the expected query is open more than once on the Datapoint, this will be noted in the results and the step will pass.

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.

Then there should be a closed query on "{datapoint}"

Then there should be a closed query on "SCREEN.VS.SYSBP[0]"
  """
  Patients SYSBP is too high. Please clarify
  """

This step checks that a closed query exists on a particular Datapoint.