ProjectConfig should be auto-scanned, not in the specific package

Currently, the ProjectConfig class must be placed at io.kotlintest.provided, or else it won’t be discovered and won’t work as per the documentation.

However, this is not very good for users. I want to create my ProjectConfig anywhere (for example, my own package me.kerooker.test.configs), and KotlinTest should work with it.

[lwasyl]

Since the issue is already here, I’ll try to argue for reopening it to search for better alternative than right now.

In our case the issue is that we have multiple modules, and would like to have both project-wide (to set isolation mode) and module-wide (to add e.g. Android-related watchers) configurations. Right now the only reasonable solution is to subclass AbstractProjectConfig in the common module and then subclass it again in each module, some of which will maybe also provide some own configuration.

The thing is it doesn’t compose well. For example with Gradle’s new testFixtures functionality it’d be nice to be able to contribute watchers to set and clean up some state relevant to specific module for example.

Perhaps it’d make sense to allow providing listeners, filters and extensions, while still requiring single point of truth for execution order, timeout etc.?

[sksamuel]

With https://github.com/kotlintest/kotlintest/commit/56afd7f057a14e837c7576bcb0c98db649c0f07c the project config is now using classpath scanning. There is no project config merging because there are settings that do no stack. The first detected config will win out (we could warn / error if mutliple?)

But with #1143 we will also start scanning for project wide listeners and extensions, so they do not need to be explicitly added to anything. This will better address the feature request of multiple config files.