Allow configuration per specification about kotest

[sksamuel]

I like the idea.

On 27 June 2016 at 21:21, Christian Helmbold [email protected]
wrote:

At the moment config is only available per test case. But it would be
useful to have a configuration per specification class, that could be
overridden per test case if necessary. My suggestion is as follows:

Instantiating a TestConfig object directly and assign it to an overridden
property :

class MySpec : StringSpec() {
override val config = TestConfig(threads = 10, invocations = 100)
...
}

or using a factory method instead of a direct instantiation:

class MySpec : StringSpec() {
override val config = config(threads = 10, invocations = 100)
...
}

(If TestConfig would be renamed to just Config both variants were almost
the same from a users perspective.)

Another option would be to call a config method inside the init block and
don't use an overridden property, but I prefer a property.

class MySpec : StringSpec() {
init {
config(threads = 10, invocations = 100)

    ...
}

}

I think a class wide configuration should reside on the class level as in
the examples with the property.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#44, or mute the thread
https://github.com/notifications/unsubscribe/AAtZGgQ_DB4aKlu0l0dP6SjTe7LrtgpQks5qQDDfgaJpZM4I_eEb
.

[helmbold]

What variant do you prefer? Or do you have another suggestion?

[sksamuel]

I think the override fits in better with the afterAll, oneInstance, etc

On 27 June 2016 at 21:25, Christian Helmbold [email protected]
wrote:

What variant do you prefer? Or do you have another suggestion?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#44 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAtZGsh0puq_u8f2rnJMozm3r2OHI1J5ks5qQDHQgaJpZM4I_eEb
.

[helmbold]

Ok, following this approach, it would be consistent to leave out config and provide properties like threads or ignored directly:

class MySpec : StringSpec() {
    override val threads = 10
    override val invocations = 100
    override val ignored = true
    ...
}

What do you think?

[sksamuel]

I guess that is consistent, but then again the DSL style can be more powerful. I guess we can always add more later.

Let's go with the overrides.

[helmbold]

OK, we agree that overrides are the best way. But after some time thinking about it, I tend to use override with the TestConfig object or config method, since a property like threads doesn't belong to the specification class itself. Whereas oneInstancePerTest does belong to the class. So it could be confusing to have per class and per test case parameters at the same level. To be self explanatory it would need a name like threadsPerTestCase or something like that. And then it would be better to use a config object with a property name that makes clear that this config is per test case and not per class. My preferred way is this:

class MySpec : StringSpec() {
    override val defaultTestCaseConfig = config(threads = 10, invocations = 100)
    ...
}

I think using a config factory method would be good, so that we would have the same syntax as for configuration per test case. Less to remember is better.

[sksamuel]

Ok I think we can go with that.

On 28 June 2016 at 10:47, Christian Helmbold [email protected]
wrote:

OK, we agree that overrides are the best way. But after some time thinking
about it, I tend to use override with the TestConfig object or config
method, since a property like threads doesn't belong to the specification
class itself. Whereas oneInstancePerTest does belong to the class. So it
could be confusing to have per class and per test case parameters at the
same level. To be self explanatory it would need a name like
threadsPerTestCase or something like that. And then it would be better to
use a config object with a property name that makes clear that this config
is per test case and not per class. My preferred way is this:

class MySpec : StringSpec() {
override val defaultTestCaseConfig = config(threads = 10, invocations = 100)
...
}

I think using a config factory method would be good to have the same
syntax as for configuration per test case. Less to remember is better.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#44 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAtZGvTFk2_WLoQi4iY6j0bZ8UBVp5l7ks5qQO21gaJpZM4I_eEb
.

[helmbold]

OK, I'll implement as suggested.

[helmbold]

I've made TestConfig immutable to avoid strange behavior I've discovered while developing. We should try to make as much as possible immutable.