nitunit: update documentation for annotations

[nit.git] / share / man / nitunit.md

diff --git a/share/man/nitunit.md b/share/man/nitunit.md
index 23b7382..2263bd3 100644 (file)
--- a/share/man/nitunit.md
+++ b/share/man/nitunit.md
@@ -129,20 +129,26 @@ This flag can be used by libraries and program to prevent (or limit) the executi
 
 ## Working with `TestSuites`
 
-TestSuites are Nit files that define a set of TestCases for a particular module.
+TestSuites are Nit modules that define a set of TestCases.
 
-The test suite 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`.
+
+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:
 
 ~~~~
 # test suite for module `foo`
-module test_foo
+module test_foo is test
+
 import foo # can be intrude to test private things
+
 class TestFoo
+    test
+
     # test case for `foo::Foo::baz`
-    fun test_baz do
+    fun baz is test do
         var subject = new Foo
         assert subject.baz(1, 2) == 3
     end
@@ -153,16 +159,18 @@ Test suite can be executed using the same `nitunit` command:
 
     $ nitunit foo.nit
 
-`nitunit` will execute a test for each method named `test_*` in a class named `Test*`
-so multiple tests can be executed for a single method:
+`nitunit` will execute a test for each method with the `test` annotation in a class
+also annotated with `test` so multiple tests can be executed for a single method:
 
 ~~~~
 class TestFoo
-    fun test_baz_1 do
+    test
+
+    fun baz_1 is test do
         var subject = new Foo
         assert subject.baz(1, 2) == 3
     end
-    fun test_baz_2 do
+    fun baz_2 is test do
         var subject = new Foo
         assert subject.baz(1, -2) == -1
     end
@@ -195,9 +203,12 @@ The `diff(1)` command is used to perform the comparison.
 The test is failed if non-zero is returned by `diff`.
 
 ~~~
-module test_mod is test_suite
+module test_mod is test
+
 class TestFoo
-       fun test_bar do
+       test
+
+       fun bar is test do
                print "Hello!"
        end
 end
@@ -216,24 +227,27 @@ To helps the management of the expected results, the option `--autosav` can be u
 
 ## Configuring TestSuites
 
-`TestSuites` also provide methods to configure the test run:
-
-`before_test` and `after_test`: methods called before/after each test case.
+`TestSuite`s also provide annotations to configure the test run:
+`before` and `after` annotations can be applied to methods that must be called before/after each test case.
 They can be used to factorize repetitive tasks:
 
 ~~~~
 class TestFoo
+    test
+
     var subject: Foo
+
     # Mandatory empty init
     init do end
+
     # Method executed before each test
-    fun before_test do
+    fun set_up is before do
         subject = new Foo
     end
-    fun test_baz_1 do
+    fun baz_1 is test do
         assert subject.baz(1, 2) == 3
     end
-    fun test_baz_2 do
+    fun baz_2 is test do
         assert subject.baz(1, -2) == -1
     end
 end
@@ -241,7 +255,7 @@ end
 
 When using custom test attributes, an empty `init` must be declared to allow automatic test running.
 
-`before_module` and `after_module`: methods called before/after each test suite.
+`before_all` and `after_all` annotations can be applied to methods that must be called before/after each test suite.
 They have to be declared at top level:
 
 ~~~~
@@ -261,6 +275,23 @@ fun after_module do
 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
+    test
+
+    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...
@@ -308,9 +339,6 @@ Only run test case with name that match pattern.
 
 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.
 
@@ -321,6 +349,13 @@ If a test-case of a test-suite passes but that some output is generated, then an
 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`
@@ -366,6 +401,10 @@ To solve this issue, `NIT_TESTING_ID` is initialized with a distinct integer ide
 
 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