## Working with `TestSuites`
-TestSuites are Nit files that define a set of `TestSuite`s for a particular
-module.
+TestSuites are Nit modules that define a set of TestCases.
-The test suiteās module must be called `test_` followed by the name of the
-module to test. So for the module `foo.nit` the test suite will be called
-`test_foo.nit`.
+A test suite is a module that uses the annotation `is test_suite`.
+
+It is common that a test suite focuses on testing a single module.
+In this case, the name of the test_suite is often `test_foo.nit` where `foo.nit` is the tested module.
The structure of a test suite is the following:
end
~~~~
+## Accessing the test suite environment
+
+The `NIT_TESTING_PATH` environment variable contains the current test suite
+file path.
+Nitunit define this variable before the execution of each test suite.
+It can be used to access files based on the current test_suite location:
+
+~~~
+class TestWithPath
+ super TestSuite
+
+ fun test_suite_path do
+ assert "NIT_TESTING_PATH".environ != ""
+ end
+end
+~~~
+
## Generating test suites
Write test suites for big modules can be a repetitive and boring task...
Examples: `TestFoo`, `TestFoo*`, `TestFoo::test_foo`, `TestFoo::test_foo*`, `test_foo`, `test_foo*`
-### `-t`, `--target-file`
-Specify test suite location.
-
### `--autosav`
Automatically create/update .res files for black box testing.
It is expected that the created/updated files are checked since the tests are considered passed.
A VCS like `git` is often a good tool to check the creation and modification of those files.
+### `--no-time`
+Disable time information in XML.
+
+This is used to have reproducible XML results.
+
+This option is automatically activated if `NIT_TESTING` is set.
+
## SUITE GENERATION
### `--gen-suite`
Note: `rand` is not a recommended way to get a distinct identifier because its randomness is disabled by default. See `SRAND`.
+### `NIT_TESTING_PATH`
+
+Only available for test suites.
+Contains the module test suite path.
# SEE ALSO