data driven testing for non hierarchical test runners

[robstoll]

Platform (JVM, JS and/or Android): all

Code related feature

In case one does not have a test runner which supports hierarchical runs, it becomes cumbersome to test data driven. Atrium is not intended for data driven testing in the narrowed sense in terms that it cannot produce multiple tests, but it already provides the necessities to assert more than one case within one test.

This feature request aims at improving the way of using the capabilities.
Currently one can do the following:

fun myFun(i: Int): String = if (i > 0) {
    i.toString()
} else {
    "no no no"
}

assert("calling myFun with...") {
    mapOf(
        -1 to "1", 
        0 to "0",
        1 to "12", 
        2 to "32"
    ).forEach { arg, expectedResult ->
        val result = myFun(arg)
        addAssertion(AssertImpl.builder.feature
            .withDescriptionAndRepresentation(Untranslatable { arg.toString() }, result)
            .withAssertion(
                AssertImpl.collector.collect(this) {
                    AssertImpl.changeSubject(this){ result }.toBe(expectedResult)
                }
            )
            .build()
        )
    }
}

As we can see, this is only for advanced users (knowing AssertImpl) and definitely belongs into an assertion function and not into test code.
The reporting looks then as follows:

assert: "calling myFun with..."        <1068824137>
◆ ▶ -1: "no no no"        <1252585652>
    ◾ to be: "1"        <2036368507>
◆ ▶ 0: "no no no"        <1252585652>
    ◾ to be: "0"        <1785210046>
◆ ▶ 1: "1"        <1552787810>
    ◾ to be: "12"        <1361960727>
◆ ▶ 2: "2"        <739498517>
    ◾ to be: "32"        <125130493>

I imagine something like:

fun myFun(i: Int): String = if (i > 0) {
    i.toString()
} else {
    "no no no"
}

assert("calling myFun with...") {
    mapOf(
        -1 to "1", 
        0 to "0",
        1 to "12", 
        2 to "32"
    ).forEach { arg, expectedResult ->
        feature(arg, { myFun(arg) }) { toBe(expectedResult) }
    }
}

[robstoll]

Maybe its better if we don't use an assertion verb for this, not Assert respectively, so that we do not pollute the API? On the other hand, it would be a shortcut to create a feature assertion out of the blue, could be handy in other places as well..

[robstoll]

This is closely related to #40 -- meaning we could also write:

feature { f(::myFun, arg) }.toBe(expectedResult)

Which results in:

assert: "calling myFun with..."        <1608446010>
◆ ▶ myFun(-1): "no no no"        <914504136>
    ◾ to be: "1"        <166239592>
◆ ▶ myFun(0): "no no no"        <914504136>
    ◾ to be: "0"        <991505714>
◆ ▶ myFun(1): "1"        <385242642>
    ◾ to be: "12"        <824009085>
◆ ▶ myFun(2): "2"        <2085857771>
    ◾ to be: "32"        <248609774>

[robstoll]

That said, one can already use property and returnValueOf and get the same behaviour. I think we don't need something for now, the myFun might be a bit redundant in reporting but so what...

[robstoll]

We could document data driven testing in README though