Dependent test

[master-bytes-krafter]

Hello
Do you propose an idiomatic way to write test/groups of tests that depend on the outcome of other tests (i.e pointless to run if some other test failed) ?
This is particularly interesting to test some scenarios during integration testing and some testing frameworks provide this feature (e.g: TestNG)

Regards

[sksamuel]

Do you mean the @Test(dependsOnMethods = { "initEnvironmentTest" }) that TestNG provides?

[master-bytes-krafter]

Hello, yes exactly, same mechanics as dependsOnMethods or dependsOnGroups. The main goal here is to avoid runing some tests (potentialy costly) when we know that they will fall anyway because the system is in shambles :)
Regards

[sksamuel]

Seems like a good idea. The annotation based syntax won't work for kotlintest though, perhaps as part of the test config.

"this is my test".config(dependencies = "some other test") {

or "This is my test").dependencies("some other test").config(...) {

[master-bytes-krafter]

Yes it would be perfect.
Now, how do yo want to proceed ? do you want me to contribute and create a PR/MR to kotlintest ? or is it something you would like to implement by yourself ?

[sksamuel]

Happy for you to create a PR.

…

On Tue, 21 May 2019 at 23:50, master-bytes-krafter ***@***.***> wrote: Yes it would be perfect. Now, how do yo want to proceed ? do you want me to contribute and create a PR/MR to kotlintest ? or is it something you are interested to implement by yourself ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#774>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFVSGQXDQTNR3QN6OA3GQDPWTGJ5ANCNFSM4HOENM2Q> .

[master-bytes-krafter]

Will gladly do

[master-bytes-krafter]

Hello all,
FYI I started working on the implementation of this feature. One question, how fast you guys check and integrate pull request ?
Regards

[sksamuel]

We are lightning fast :p

…

On Fri, 7 Jun 2019 at 13:20, master-bytes-krafter ***@***.***> wrote: Hello all, FYI I started working on the implementation of this feature. One question, how fast you guys check and integrate pull request ? Regards — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#774>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFVSGTECNSUT33MR7EQT23PZKRHZANCNFSM4HOENM2Q> .

[sksamuel]

If we have something workable we can target 3.4 for this.

[master-bytes-krafter]

After testing for two days here are my thoughts:

• This feature is not quite simple to implement => specs dependencies need to be handled differently than test dependencies. Top level tests do not have a config (not 100% sure though)
• However i found a possible workaround that is acceptable for my use case and it works right now, it involves the fact that tests order and specs execution order can be controlled, there can be a single instance mode and tests listeners. So dependency management can be controlled in test by test basis. The only thing is that I can fail() a test based on some conditions but i cannot skip it, but that is not a major issue, the goal being not running the time consuming part of a test.

What do you think ? Maybe this feature can be rewritten to : add a way to specify if a test can be skipped dynamically on runtime (passing a function returning a boolean in test configuration ?)

[LeoColman]

We recently added a way to skip tests in runtime, by throwing the SkipTestException #522 .

It's pending release, but you can use the snapshot if needed for the moment

[sksamuel]

@master-bytes-krafter you can use a TestExtension if you want to control whether a test is executed at runtime. Note: That is different from a TestListener.

[sksamuel]

@Kerooker this is a must have for 4.0 IMO.

[master-bytes-krafter]

Hello, sorry for the delay, FYI we found a very convenient way to do this with the current version of kotlintest. Sure it relies on ordering files and tests in certain order and requires to write a little bit of code (30 or so lines approximately), but we can live with it for now.
Of course it would be great that it was a part of kotlintest but the analysis we made concluded that for a third party contributor the investment to implement it by ourselves would be significant and we cannot implement this for now.

[sksamuel]

Marking as won't fix.

[Burtan]

Any plans for this feature?