I think that we’re talking about two different build problems here. Separating tests into groups based on speed is important because developers don’t want to wait on a build. Separating tests by function is also important because different functionality often requires a different environment (for example my integration tests need to run against my WAR in a web container, while my unit tests have no external dependencies).
The problems are related because one way of implementing fast/slow separation is by making separate a source set for each speed. This is the natural approach to splitting by function. However, I agree with Robert and PJ that separate source sets aren’t desirable when splitting tests by speed. When splitting by speed, you want to easily be able to mark a test as one or another speed without having to move it on the file system. You also want to be able to support as many speeds as you’d like without having to have an arbitrary number of top level directories.
This doesn’t work well for a division of tests by functionality though. When dividing by functionality, I would expect a user to want to be able to group supporting files with the tests. For example, database files that are only used by integration tests.
In conclusion, I think there’s two problems here that deserve separate treatment. In functional splitting (which my plugin attempts to start addressing) you want separate sourcesets for your tests. In speed splitting, you want a series of include/exclude clauses to define groups of tests.
I’d like to suggest that we branch this discussion so that the two separate use cases can get the attention they deserve without interfering with each other.