Could val container by lazy by default?

[aesteve]

Hello, and thanks for your great work! Using it on a daily basis, works like a charm.

Here's the (mini) problem I ran into.

I have a set of standard test that are run through the test (and thus build task) => they're pure unit tests or PBT, they don't need testcontainers (the faster they run the faster the feedback-loop...)

I have a set of integrationTest using testcontainers-scala. They're quite heavy-on-ressources (docker-compose, etc.). They're simply here to assert that "in a real environment, things should work". They're run through a dedicated task, not every build.

I chose to use an annotation for these integration test classes so that I can exclude them through ScalaTest tags (I'm using scalatest-gradle-plugin). But even when excluded, they're still instanciated, and thus val container = /* ... */ is still executed (checking Docker version etc.).

This is not a real problem for me, since everywhere test are run, there's a docker daemon, but it could be problematic if not.

The very simple fix for me was to declare:

@IntegrationTest
class SomeIntegrationTestNeedingTestContainers extends FeatureSpec with ForAllTestContainers {
  override lazy val container: DockerComposeContainer =  /* declaration */ 
}

This seems to work perfectly fine and achieve what I need it to achieve.
I was just wondering if other people ran into this issue? And if yes, could it be "lazy" by default?

wdyt?

[LMnet]

It could be def by default. With this, you will achieve an effect you want. And overall it is a good practice to not have vals in the traits. You can create a pull request with this change.

Also, in the near future, we will release a new API in which you will not have the issue you described.

[aesteve]

Yes obviously def works too. I did not propose this since it could be a big breaking change for end-users (having to re-write all their override val to override def should we create a PR with this? Sounds like a "breaking change" (even though it's better I agree.

We also could argue that the container shouldn't be re-created every time the method is called? (hence really being a lazy val and not def) <= not sure about this.

[LMnet]

It will not break user code — you can override def with val.

[aesteve]

Thanks, I forgot about that. Sorry to not submit a PR, but I'm leaving for 3 weeks with no internet access. I'll address this once I'm back.

Thanks for your explanations!

[aesteve]

Got a few minutes to file a PR.