Localization

test GiD
The check 'test GiD' declares that the tester is used for GiD and then provides some special features hidden in a generic test
(for example gidini or use of batch file only has sense in case of testing GiD)

basecasesdir
This field declares the folder location of all cases. It allows using relative paths in the xml and batch files (the full path is obtaining joining basecasesdir and the relative path).
Using absolute paths inside the xml and bath files a bad idea, because test definitions could be shared by different users and they could have locally its test cases in different folders.
e.g.
C:/Tester_GiD
Comment: If you want to start a external GiD and import a batch file that content relative paths, to work correctly, you must set as current directory the 'basecasesdir'
-np- cd "C:/Tester_GiD"
and then you could import the batch file in the normal way (Files->Import->Batch file)

exe
It declares the location of the exe program to be tested
e.g.
C:/gid project/gid.exe

gidini
It declares the location of gid.ini to be used to run GiD (only shown if 'test GiD' was set). This ini is used as 'read only' running GiD tests (is not changed by the tests themselves), otherwise running a test or using another GiD interactively will affect other tests.
It could be a path relative to the folder of 'exe'
e.g.
scripts/gidDefaults1024x768

platform provide
It declares that the program that we are testing uses this operating system and bits:
e.g.
Windows 32
or
Linux 64
Some test cases have only sense for some platform, in this case they must declare it with 'platform require' in its properties, then it is possible to filter all cases that doesn't have sense in the current platform provided.
For example, if a problemtype is only available compiled for Windows x32 then the test must not be done in a GiD compiled for Windows x64 or for other platforms.
(but we want to have the test in the full shared database, but hidden for unwanted platforms)

branch provide
It declares that the branch line that we are testing is the 'official branch' or the 'developer branch' (assuming that a normal program could have these lines)
e.g.
developer
or
official

Some test cases have only sense for some branch in this case they must declare it with 'branch require', then it is possible to filter all cases that doesn't have sense in the current branch provided.
For example, if a case tests a new feature only existing in the developer branch the test must not be done in the official branch.
(but we want to have the test in the full shared database, but hidden for unwanted branches)