Migrate performance tests to occur on tests project #227
Conversation
This will open up the ability to assert on JS and native which simply isn't possible with the Kotlin Compiler Testing infrastructure.
|
Here's the followup with a JS improvement that this now enables testing: https://github.com/JakeWharton/Poko/compare/jw.migrate-performance.2023-09-05...JakeWharton:Poko:jw.js-equals.2023-09-05 |
| @@ -20,4 +20,5 @@ include( | |||
| ":poko-annotations", | |||
| ":poko-gradle-plugin", | |||
| ":poko-tests", | |||
| ":poko-tests:performance", | |||
There was a problem hiding this comment.
Is there a technical reason a new module is needed, or just preference?
There was a problem hiding this comment.
The tests only run once and they run on the JVM. I suppose we could keep them in the compiler module since it's only a test dependency.
There was a problem hiding this comment.
Oh right. I'm good with them here then.
There was a problem hiding this comment.
Another option is a disconnected project which consumes the artifacts through a repo-local Maven install. This was what I set up first, but the signing configuration always wants to sign things so it doesn't work and I didn't want to mess with it. This is what I usually do on other projects since you have infinite flexibility due to the disconnected project. As a downside, it's a bit more setup.
There was a problem hiding this comment.
This is all new to me and it's not obvious to me what we're missing out on due to inflexibility. But if we are missing out on something I'm open to refactor the signing logic to not get in the way.
There was a problem hiding this comment.
One example would be that you can vary the Kotlin version. If you want to test / support a range of versions at once, this would be an easy way to test those bounds.
Another thing that you can do is vary compilation properties. So instead of having to add a duplicate target for supporting K2 like you did recently, the project could be compiled twice, once with K2 and once without.
I'm not sure we're losing anything yet, but it's something to consider long term depending on how many more things come up.
This will open up the ability to assert on JS and native which simply isn't possible with the Kotlin Compiler Testing infrastructure.