This week I’ve been learning how JUnit, IntelliJ a...

# feed

[dmcg]

This week I’ve been learning how JUnit, IntelliJ and Gradle interact

https://youtu.be/tvCSZgN1g_w▾

[Emil Kantis]

Gradle's configuration cache might cut out a lot of that startup time. I'd like to give it a go and see if it helps. Which branch are you working on in the vid? I only see 82 tests on main

[dmcg]

That’s strange. I was a little behind on my pushing (I’ve just brought it up to date). I count 124 @Test annotations. and the run configuration runs 134 tests in total.

[dmcg]

I had planned to look at more gradle caching, plus not running the flywayMigrate task unless its out of date, so would be grateful for any input

[dmcg]

Oh, and I’ve just discovered --profile 🙂

[Emil Kantis]

Managed to tune it a bit, but I was forced to do some things I"d rather not have done in a real project.

changes
feel free to check it out at https://github.com/kantis/gilded-rose-tdd to see how it compares. 🙂

[Emil Kantis]

As for the "missing" tests.. I thought I had your repo checked out, but it was a fork I created some 2 years ago 😄

[dmcg]

Thank you! One of the biggest problems with Gradle is that you can persuade it to do most anything, but you know you are lighting a maintenance fuse that at some point (Gradle upgrade, new plugin…) will make things explode in your face.

[dmcg]

I’ll take a detailed look over the weekend

[Emil Kantis]

Yeah, I agree. You really shouldn't be creating custom Gradle tasks/plugins unless you have a dedicated build engineer or the main goal is to actually ship a Gradle plugin. (Convention plugins are a different matter though)

In this case, Flyway doesn't support Gradle configuration caching, and they closed the issue stating that they are not actually planning on supporting it.

I found a workaround for dealing with that, but in a real project I'd look into replacing Flyway or just accept the fact that Flyway will slow down the build (and all startups, etc...). Feel free to DM if you want to discuss further 😄

[dmcg]

Thank you. It’s nasty nasty nasty but I can at least get flyway to not try to migrate by tying it to the jooq generated classes

tasks.named("flywayMigrate") {
    inputs.files("src/main/resources/db/migration")
    outputs.dir("build/generated-src/jooq/main")
}

tasks.named<nu.studer.gradle.jooq.JooqGenerate>("generateJooq") {
    dependsOn("flywayMigrate")
    inputs.files("src/main/resources/db/migration")
    allInputsDeclared = true
}

I’m sure that I could remove the duplication, but it does at least appear to work

[dmcg]

Will look at Lukas’s proper task - last time I did there was practically no documentation except read the XML schema

[mikehearn]

Thanks for these tips! I've just been applying them to my project. Most I already knew a about and was using, but I'd forgotten about the IntelliJ test runner, which gives nicer progress tracking in any event.

[dmcg]

It’s a shame that IJ has lost the ability to build, because measuring it seems that using its runner is maybe 150ms slower overall. But, as you say, the experience is better

[mikehearn]

Yes, and JPS is an extremely fast build system.

[mikehearn]

Unfortunately, not flexible enough. So people go to gradle and then JPS sync is an endless source of bugs, so, Gradle wins. With config cache (when it works) it can be fast enough.