chore: enable implicit default logger only in testing with -v

[apstndb]

What does this PR do?

This PR changes -v and -test.v=true handling only takes effect if testing.Testing() = true, i.e. go test.

Why is it important?

The current implementation always treats -v and -test.v=true specially, even outside of go test, and outputs verbose logs that are not easy to suppress. This makes it difficult to use testcontainers outside of go test.

Related issues

• Closes [Bug]: -v enable logs which is not intuitive to control #2874

How to test this PR

These behaviors should not be changed.

$ go test
$ go test -v
$ go test -test.v=true

These behavior will be changed to suppress default logging.

$ go run ./ -v

[netlify]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	629a514
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-go/deploys/6746a72490587a00081a5b4d
😎 Deploy Preview	https://deploy-preview-2877--testcontainers-go.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mdelapenya]

@apstndb thanks for opening the issue and working on the fix. I have one question about your use case: What do you expect when go run -v is executed?

From what I can see with the implementation in this PR, for the use case above of executing go run -v, we are going to always suppress the logging. I'd expect the -v flag enables the logging.

Could you share more on your use case so we can understand better the needs behind it? 🙏

[apstndb]

My expectation is that go run ./(or binary built by go build) won't generally follow go test convention.

• It won't know -test.v=true.
• It can use --verbose or -vv for vebose mode, and it can even use -v for other purpose.

It means the current behavior of enforcing go test convention to go run ./ is not good.

In this case, users can implement their own handling by explicitly setting testcontainers.Logger = logger or testcontainers.WithLogger(logger). It is not hard.

[mdelapenya]

@apstndb so IIUC, you are using testcontainers-go outside a test suite as, my guess, the runtime of a software that spins up containers, right?

Then I think you're right and we should consider this, but want to double check with you about your use case.

[apstndb]

so IIUC, you are using testcontainers-go outside a test suite as, my guess, the runtime of a software that spins up containers, right?

Yes!
This is a combination of interactive tools and the Spanner emulator, so you could call it testing in the broadest sense, but it has nothing to do with the go test framework or unit testing.

[mdelapenya]

@stevenh and I are in conversations to refactor the library logger.

In the mean time, @stevenh, do you think we can make progress and merge this one without affecting our goals? I think this change is fair simple, so harmless to merge.

[mdelapenya]

LGTM, thanks!

[mdelapenya]

@apstndb one final question: in your case, using tc-go as part of another library, how would you get testcontainers logs? IIUC this code, it will enable the verbose mode only when testing is enabled, which is not your case, right?

[apstndb]

IIUC this code, it will enable the verbose mode only when testing is enabled, which is not your case, right?

It is right, my case don't show tc-go logs currently.

in your case, using tc-go as part of another library, how would you get testcontainers logs?

I think we can pass some options to the wrapper library like EnableLogs() or LogOutput(writer) explicitly.
IFAIK, some logs ("Relevant log output" of issue #2874 ) rely on default logger and not configurable using container logger. I think it shouldn't be.