nitunit: split module into one executable and a group named `testing`.

Introduce module `test_doc` that implements "doc-units".

Signed-off-by: Alexandre Terrasa <alexandre@moz-code.org>
nitunit: factorize test_dir processing into test_base.

Signed-off-by: Alexandre Terrasa <alexandre@moz-code.org>
nitunit: allow testing from external files called test-suites.

Signed-off-by: Alexandre Terrasa <alexandre@moz-code.org>
nitunit: allow test-suite skeleton generation.

Signed-off-by: Alexandre Terrasa <alexandre@moz-code.org>
nitunit: add README for group `testing` and redirect from nitunit doc.

Signed-off-by: Alexandre Terrasa <alexandre@moz-code.org>
lib: java is a group

Signed-off-by: Alexis Laferrière <alexis.laf@xymus.net>
java: move `android::java_io` to `java::io` & remove refs to android

Signed-off-by: Alexis Laferrière <alexis.laf@xymus.net>
android: update users of `java::io`

Signed-off-by: Alexis Laferrière <alexis.laf@xymus.net>
tests: remove java_io from cc.skip

Signed-off-by: Alexis Laferrière <alexis.laf@xymus.net>
nitunit: update tests.

Signed-off-by: Alexandre Terrasa <alexandre@moz-code.org>
lib/standard/string: Proper handling of trivial cases in substring_from.

Signed-off-by: Lucas Bajolet <r4pass@hotmail.com>
lib/standard/string: bugfix in Array::to_s when encoutering another structure than a FlatString

Signed-off-by: Lucas Bajolet <r4pass@hotmail.com>
tests: Added test for the special case of Array.to_s with a Rope.

Signed-off-by: Lucas Bajolet <r4pass@hotmail.com>
Merge: Move `android::java_io` to `java::io`

Fix #696

Pull-Request: #705
Reviewed-by: Jean Privat <jean@pryen.org>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>
Merge: Nitunit: Allow external test files.

Unit testing can now be achieved in two ways:

* using `DocUnits` in code comments
* using `TestSuites` with test unit files

`DocUnits` are executable pieces of code found in the documentation of modules,
classes and properties.
They are used for documentation purpose, they should be kept simple and illustrative.
More advanced unit testing can be done using TestSuites.

`TestSuites` are test files coupled to a tested module.
They contain a list of test methods called TestCase.

## Working with `DocUnits`

With DocUnits, executable code can be placed in comments of modules, classes and properties.
 The execution can be verified using `assert`

 Example with a class:

    module foo
    #    var foo = new Foo
    #    assert foo.bar == 10
    class Foo
        var bar = 10
    end

 Everything used in the test must be declared.
To test a method you have to instanciate its class:

    module foo
    #    var foo = new Foo
    #    assert foo.bar == 10
    class Foo
        #    var foo = new Foo
        #    assert foo.baz(1, 2) == 3
        fun baz(a, b: Int) do return a + b
    end

 `nitunit` is used to test Nit files:

    $ nitunit foo.nit

## Working with `TestSuites`

 TestSuites are Nit files that define a set of TestCase for a particular module.

 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`.

 The structure of a test suite is the following:

    # test suite for module `foo`
    module test_foo
    import foo # can be intrude to test private things
    class TestFoo
        # test case for `foo::Foo::baz`
        fun test_baz do
            var subject = new Foo
            assert subject.baz(1, 2) == 3
        end
    end

 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:

    class TestFoo
        fun test_baz_1 do
            var subject = new Foo
            assert subject.baz(1, 2) == 3
        end
        fun test_baz_2 do
            var subject = new Foo
            assert subject.baz(1, -2) == -1
        end
    end

 `TestSuites` also provide methods to configure the test run:

 `before_test` and `after_test`: methods called before/after each test case.
 They can be used to factorize repetitive tasks:

    class TestFoo
        var subject: Foo
        # Mandatory empty init
        init do end
        # Method executed before each test
        fun before_test do
            subject = new Foo
        end
        fun test_baz_1 do
            assert subject.baz(1, 2) == 3
        end
        fun test_baz_2 do
            assert subject.baz(1, -2) == -1
        end
    end

 When using custom test attributes, a empty init must be declared to allow automatic test running.

 `before_module` and `after_module`: methods called before/after each test suite.
 They have to be declared at top level:

    module test_bdd_connector
    import bdd_connector
    # Testing the bdd_connector
    class TestConnector
        # test cases using a server
    end
    # Method executed before testing the module
    fun before_module do
        # start server before all test cases
    end
    # Method executed after testing the module
    fun after_module do
        # stop server after all test cases
    end

## Generating test suites

 Write test suites for big modules can be a pepetitive and boring task...
 To make it easier, `nitunit` can generate test skeletons for Nit modules:

    $ nitunit --gen-suite foo.nit

 This will generate the test suite `test_foo` containing test case stubs for all public
 methods found in `foo.nit`.

 Useful options with `--gen-suite`:

* `--private`: also generate tests for protected and private methods
* `--force`: force generation of the skeleton (existing test suite will be overwritten)

Pull-Request: #627
Reviewed-by: Jean Privat <jean@pryen.org>
Reviewed-by: Alexis Laferrière <alexis.laf@xymus.net>
Reviewed-by: Lucas Bajolet <r4pass@hotmail.com>
lib/standard/string: reverse iterator fix on substring. Fixes #709

Signed-off-by: Lucas Bajolet <r4pass@hotmail.com>
Merge: String: Bugfixes

When rewriting the to_s method in Array, an error was subtle enough to fight its way through the tests but was discovered when reworking the Ropes (yup, be prepared, it'll appear once more).

Oh and there was a bug in the substring_from method (well, more of a lack of efficiency then a real bug).

Pull-Request: #699
Reviewed-by: Jean Privat <jean@pryen.org>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>
Reviewed-by: Alexis Laferrière <alexis.laf@xymus.net>