Selenium Pipeline Tests

If you're writing pipeline tests, instead of your test class extending BaseTestCase directly, you should instead extend BasePipelineTest. Since BasePipelineTest extends BaseTestCase already, you still get all of the goodies for free mentioned in the previous section: Test Structure, but now you get some added benefits:

1. BasePipelineTest also includes the PipelineMethodSorter. Read more about it here: PipelineMethodSorter.
2. Testing a pipeline should be split up into two steps. First, you should create a test called "testLaunch<Pipeline name>". The performPipelineTest() method (when the test is given the correct annotation: Pipeline Annotations), takes care of everything necessary to log in to XNAT, find the session, get to the pipeline launch page, and logout after launching the pipeline. The only part of the test that differs per pipeline is what to do once the correct pipeline has been selected. To describe these steps, add elements extending PipelineConfigElement to the config object set up in the test by default. These elements are atomic actions to provide the steps for launching the pipeline in XNAT. Elements supported out of the box include:
   • AlertElement - used to close browser level alerts.
   • AssertTextElement - used to ensure some WebElement has certain text.
   • ClickElement - used to click on a WebElement
   • FillElement - used to enter a value in a WebElement
   • SelectElement - used to select an option from a dropdown
   • TestStepElement - used to post a step to JIRA (if enabled) with a screenshot of input WebElement objects
   
   The second test created should be called "testCheck<Pipeline name>". The first method called in one of these tests should be checkPipelineTest(), after adding various objects to the List<ProcessingCheckable> processingCheckables object inherited from the base class. There are 3 implementing classes for ProcessingCheckable at the moment:
   1. CreatedAssessor: pass an instance of org.nrg.xnat.pogo.DataType to the constructor. When the test determines that the pipeline has completed successfully, it checks the current session to ensure that an instance of this type of assessor have been created successfully.
   2. GeneratedEmail: using the addMessageContainCriterion(String) and addSubjectCheck(String) methods, you can specify an email that with a body containing a certain String, or with a subject exactly equal to a certain String, respectively. A check will automatically be added that the email must have been received after the start of the test suite.
   3. ProcessingFileSetRequest: the String in the constructor refers to the name of a YAML file that must be stored in XNAT in the "validation" resource directory for the session on which the pipeline is running. Then, this file will be pulled down and processed to create a list of various checks to ensure that the pipeline created files correctly. This is described in more detail here: Advanced Usage: FileComparator and FileMutator.
      
      
   The other capability for asserting results comes from the compareTable(...) method. This method is powered by a YAML file which should again be stored under the "validation" session resource folder. This method identifies elements on the page and ensures that they satisfy some arbitrary criteria. The YAML format is covered here: Advanced Usage: ElementComparators.