xmls

Past structure of xmls folder:
In the past this folder contained this structure of folders, to separate the cases that are expected to be run only by the developer version (only developer) and the cases that could be run by both (official and developer versions).
\xmls
        \common
                       \cases_running
                       \cases_failing
        \only developer
                         \cases_running
                         \cases_failing

cases_running and cases_failing folders classify depending on if the test cases must be run successfully (cases_running) or if they will fail and the error is not solved yet (cases_failing).
Inside these could be an arbitrary number of xmls and its name was important to classify the cases as a tree. There was being one xml file for each family of test cases (for example, mesh_structured.xml, geom_intersection.xml, etc...). Big test cases, which may take a lot of memory, and may last a lot of time, were in specific xml's, in order to avoid the running simultaneously with other test cases to not collapse the computer.

Current structure of xmls folders:
Now all cases are defined in a single xml file, named 'tester_cases.xml', and this file is controlled by the CVS (to synchronize several users sharing its information).
The information of common/only_developer cases_running/cases_failing and 'tree classification' is now stored in the definition of each case.

Note: The old style could be already used to import some external cases (once imported its data is stored 'in tester_cases.xml' and the auxiliary files are not needed more)

File structure of tester_cases.xml:
The file content must be like this:

<?xml version="1.0" encoding="utf-8"?>
<cases version="1.0">  
   <case>
      case fields
   </case>
    ...
   <case>
   </case>
</cases>

Case fields:
For each case is possible to use these keys, most of them are optional:
It is not necessary to know this syntax, the normal way is to fill the information in the GUI to define or modify a case.

General fields:
These fields are defined also in the preferences window, and it is not necessary to specify them again in each tests case: they must be set only if it's different of the general one!!

• <maxprocess> this is the number of test cases to be run simultaneously.
• <timeout> this indicates the timeout (in seconds) after which the process of the test case is killed.
• <exe> this indicates the path of the gid.exe to be run for the test cases. But don't use it: the '.exe' file must be set from the general preferences of the tester program, the same for all tests. The<exe>field can also be a.bat file. This field can also be specified inside <case>...</case>
• <gidini> An specific gid.ini can be used for each test case, avoiding the use of the gid.ini shared by all the GiD's of the computer. The gid.ini's must be placed in the gid_inis folder. It is recommended to use a relative location (relative to the folder of the exe)

Only case fields:

• <name> to identify the case.
• id: case attribute that identify the case with a unique id, it is not assigned manually but automatically (when importing or creating a new case).
• <help> To add some comment, for each case this help could be shown from its contextual menu.
• <owner> this indicates the responsible of the test case. It should be the e-mail address of the responsible (to be used in the future to send him warnings)
• <tags> An ordered list of words, used to classify the cases as a tree (in case of select this kind of view)
• <args> for general use of tester: arguments to append when invoking the exe (e.g: -b "batch_filename", -offscreen -b+g "batch")
• <environment> for general use of tester to set values of environment variables for a process. It is a flat list of <key_1> <value_1>  ... <key_n> <value_n>  (e.g. <environment>OMP_NUM_THREADS 4</environment>)
• <batch> for automatic launch GiD without window a GiD batch file (it is possible to start also with window from the contextual menu)

More simple than generic 'args' for a GiD batch file, to be run without windows with -n -b "batchfile"

• <platform_require> To declare that the test will only run if the exe is declared of this platform. It is a list with two values: OS (Windows Linux MacOSX) and bits (32 64).

wildcards * are allowed. e.g. "* 64" mean a case that could be run on each OS but only x64 (e.g. because require more than 2GB available in x32 by process)
Activating filters is possible (and recommended) to hide the case with platform required not provided.

• branch_require Optional case attribute to declare that the test will only run if the exe is declared providing this branch (developer or official) or empty.

Activating filters is possible (and recommended) to hide the case with branch required not provided. (empty default)

• fail_accepted Optional case attribute to declare that the test is expected to fail if its value is 1 (0 default). It represents the old 'cases_failing' folder.
• <outfile> output filename where readingproc will expects to read information, can use "stdout" to send standard output to readingproc instead $outfile.

By default, testing GiD, the readingproc is the procedure read_gid_monitoring_info, and outfile filename is automatically created in the temporary folder when running the test. The file will contain a list of key value key value ... of variables that are asked to GiD to be used to check if the test fail (only variables used in checks will be asked to GiD and written in the implicit outfile).

• <readingproc> callback procedure to invoke after run with $outfile as argument, it is expected to return a list of variable1 value1 ... variable_n value_n, and these variables can be used in check fields  (by default "read_gid_monitoring_info { outfile }" will be called to read GiD information)
• <filetosource> tcl filename to be sourced (e.g.: to define other reading procedures)
• <codetosource> tcl code to be sourced (e.g.: to define other reading procedures)
• <outputfile> declares an output file created by the test, it can be an image, a movie, a txt, a html, ...

outputfile-1 ... outputfile-n : in case of several output files, for instance, several images.
Tester displays if the image or video was created and when clicking on them will display them. When creating the HTML output, the image is included or a link to the video file.
Now use of this field is not well implemented, because each test must write only in its temporary folder, it is not a good idea to write in any tester folder (different tests could use the same filename) or write in the test model folder, to avoid modify them.
In the future only writing in temporary folders, or user preferences folder must be allowed (e.g. to install tester in program files, where is required administrator permission to write, or models that could be in a read-only repository folder)

• <check> things to be checked. Inside could have several sub-checks, named for example <check-1> ..<check-n>

It will be tested if the content is true, as a Tcl expression.

Example of a general case

  <case>
    <name>cmd.exe stdout</name>
    <help>tester sample of a program different of GiD, e.g. Windows cmd.exe</help>
    <exe>cmd.exe</exe>
    <args>/c date /t</args>
    <outfile>stdout</outfile>
    <readingproc>::tester::myownread</readingproc>
    <codetosource>
      proc ::tester::myownread { all } {
      scan $all "%d/%d/%d" dd mm yyyy
      set res [list day $dd month $mm year $yyyy]
      return $res
      }
    </codetosource>
    <check>
      <rule-1>$day>=1 && $day<=365</rule-1>
      <monthandyear>($month>1 && $month<12) && $year>=2007</monthandyear>
    </check>
  </case>

Example of a GiD case

  <case>
    <name>GiD 8.0.9 : camp1_8_s</name>
    <help>must fail one check of number of nodes</help>
    <exe>C:\Program Files\GiD\GiD 8.0.9\gid.exe</exe>
    <args>-b cases/iges_bch/camp1_8_s.bch -n</args>
    <timeout>3600</timeout>
    <check>
      <numnodes>$numnodes>1</numnodes>
      <numnodes-2>$numnodes>80000</numnodes-2>
    </check>
  </case>

Note that instead <args> could use the more simple syntax
<batch>cases/iges_bch/camp1_8_s.bch</batch>

Another example

  <exe>C:\gid project\gid_offscreen.bat</exe>
  <exe platform="Linux">/home/gid/gid_off</exe>  
  <exe username="miguel">C:\GiD64\gid_offscreen.bat</exe>
  <exe username="miguel" platform="Linux">/home/miguel/GID/gid/gid_off</exe>  
  <case>
    <help>OFF_Preprocess: batch launches tcl, creates geometry (using another batch), meshes, png and quits</help>
    <name>OFF_PreBatchBasic</name>
    <args>-offscreen -b+g "batchs/Pre/OffScreen/flapslat_batch00.bch"</args>
    <outputfile-1>flapslat_geom.png</outputfile-1>
    <outputfile-2>flapslat_mesh.png</outputfile-2>
    <check>
      <test-1>[file size flapslat_geom.png]>0</test-1>
      <test-2>[file size flapslat_mesh.png]>0</test-2>
    </check>
  </case>