A test scenario is an XML document that follows the structure described by the rtest.xsd application schema. This application schema greatly simplifies the editing of the test scenario using an XML editor such as XMLSpy, OxygenXML or others. These tools allow for quick detection of input errors and even offer writing assistance. It is important to use a powerful tool to avoid wasting unnecessary time when editing test scenarios.
The rest of this document describes the different elements that can be found in a test scenario. The notation used is the following: /element1/element2@attr1 Where:
/element1 is the root element of the document (scenario)
element2 corresponds to an element contained in element1
attr1 is an attribute of element2
Warning
The case and order of the elements must be respected.
Description: <scenario> is the root element of all scenarios. Its content is fixed (example scenario), only the xsi:schemaLocation attribute can be modified.
This indicates that the XML editor must rely on the application schema version located at http://schemas.veremes.net/rtest/2.0/rtest.xsd
To work without an internet connection or to adapt the schema to your own needs, it is possible to copy rtest.xsd to the local directory and reference it as follows:
Description: This element groups together all the information needed to describe a test. It is possible to describe one or more elements consecutively.
Description: Each rtest element has an id attribute that allows it to be uniquely identified within the same scenario. The id attribute is of type xs:ID, so it must follow the following rules:
it must start with a letter.
it must not contain spaces, carriage returns or special characters other than the period.
Description: This element groups together all the information necessary for the description of an FME workspace (process). It is possible to describe one or more elements consecutively.
Description: These attributes list the files to be deleted before or after the FME processing is executed. The paths can be absolute or relative to the test scecnario. If there are multiple files, they must be separated by a comma. Patterns are supported. The following example shows how to delete the dbcountry.sqlite file contained in the result directory and all files with the .log extension.
If a file is locked, deletion fails and scenarioPlayer stops. A file can be used and locked by FME when running the scenarioPlayer. If this happens, you should change the file name for successive tests in the same test scenario or separate the tests in different scenarios. To reduce the risk of unintentional deletion in the event of incorrect settings, the number of files that can be deleted by a single reason is limited to 20. If such a case is detected, scenarioPlayer stops and an error message is added to the log file. Despite this limitation, you should be very careful when using the deletebefore and deleteafter parameters.
Description: These attributes define a waiting time (in seconds) before or after the FME processing is executed. They should be used when testing a complex integration chain in asynchronous mode. For example, when FME processing subcontracts some tasks to FME Server or WorkspaceRunner in asynchronous mode (without waiting for the processing to finish).
Expected value: An integer.
Example: The following process must wait 1 minute before it is executed.
Description: Allows you to specify whether the expected result is the success or failure of the workspace: Translation FAILED or Translation was SUCCESSFUL. It is sometimes useful to check that the use of certain parameters causes the processing to fail on purpose. So if the expected status is failure and the processing fails, then the html report will show a successful test.
Expected value: [failure|success], default is success
Description: Allows to force the copy of the processing log file in a directory and under a known name. This technique allows a later inspection of the log content during a verification operation.
Expected value: Absolute or relative path of the file to be produced.
Description: This element groups together all the information needed to describe a check. It is possible to describe one or more <check>elements consecutively.
Description: The element is used to calculate the value to be checked, also known as the "Observed Value". The observed value comes from a dataset. Depending on the type of dataset, it can be for example the number of records, the value of an attribute, the size of a file or the result of an SQL query.
Description: The source@type attribute defines the type of data source to be read to obtain the observed value. There are three possible types: file, datafile and database.
When scenarioPlayer encounters a data source of type file it does not try to open it but only looks at its external characteristics such as size or creation date. Currently the only function available on file data sources is fileSize() which returns the file size (in bytes) as the observed value.
Data sources of type datafile must be associated with a format (cf.source@format). They can then be read by scenarioPlayer with the correct FME Reader. The functions available to calculate the value observed on this type of files are : featuresCount(), attributeValue(), featuresCountByFtAndGeometry()
The logfile type is used to search for a pattern in a text file. It is not necessary to specify the format of the dataset. The source@dataset is read line by line and each line is compared with the expected value. If at least one line matches, the validation is set to "Success", otherwise it is set to "Failed". The match comparator is well suited to handle this type of file by allowing a comparison pattern to be defined in condition@expectedvalue. The logfile type is frequently associated with the process@copylogto attribute which allows to create a copy of the FME processing log file. This makes it possible to search for a pattern in a file of this type.
Finally, database data sources allow to execute a SQL query on the dataset to extract the desired information. This is the most powerful mechanism for defining a check on the attribute or geometric content of a dataset.
Note
The location of the dataset, its format, and the observed value are determined by the other attributes of the element.
Description: Format to be used to read the source dataset identified by the source@dataset attribute. The list of supported formats may evolve with the versions of scenarioPlayer.
Expected value: Short name of the FME format visible in the "View Format Gallery" menu of FME Workbench. Not all formats are supported, see the list of usable formats.
Description: SQL query to be applied to the source dataset and to calculate the observed value observedvalue.
Expected Value: A string corresponding to a SQL query for the source dataset. The query must return a single value in the form of an "observedvalue" field. The spelling of "observedvalue" must be lowercase, but to simplify the writing of Oracle queries, OBSERVEDVALUE fields with this format are automatically converted to lowercase.
Examples :
For data set SPATIALITE
<sourcetype="database"format="SPATIALITE"dataset="result\dbcountry.sqlite"dbrequest="select name as observedvalue from country where OGC_FID=2;"/>
For data set POSTGIS
<sourcetype="database"format="POSTGIS"connection="nc_mabase"dbrequest="SELECT ST_Extent(geom) as observedvalue FROM departements.dpt_postgis;"/><conditioncomparator="eq"expectedvalue="BOX(47700 1616600,1197900 2677200)"/>
For data set ORACLE_SPATIAL
<sourcetype="database"format="ORACLE_SPATIAL"connection="nc_dpt_oracle"dbrequest="FME_SQL_DELIMITER ; SELECT CONCAT(NUM_DEP, NOM_DEP) AS observedvalue FROM ADM.DPT WHERE num_dep='66';"/><conditioncomparator="eq"expectedvalue="66PYRENEES-ORIENTALES"/>
Optional attribute, required with somerequest values
Description: requestparams should be used to refine the scope of the function called in the request attribute. For example requestparams will allow to define the name of the attribute and the index of the record concerned by the attributeValue() function.
Description: The <condition> element is used to define the reference value or "Expected Value" that should be compared to the observed value defined in the <source> element. It also defines the operator to be used to compare the two values.
