Quarkus: QuarkusUnitTest shares logging configuration between tests

Created on 22 Oct 2020  路  11Comments  路  Source: quarkusio/quarkus

I am developing an extension and writing tests for it.
With my extension, the user is able to modify level of loggers by calling a REST endpoint.

Here you can see a example test that I wrote.
They are exactly the same and do:

  • Get the current configuration and verify it is the initial configuration (should be {"configuredLeve": null, "effectiveLevel": "INFO" }
  • Change the log level of io.quarkus.loggers to TRACE
  • Verify the lo level was changed was changed to TRACE ( expected: {"configuredLeve": "TRACE", "effectiveLevel": "TRACE" })

If the tests are independent, both should pass.
When I run mvn test, I get

[ERROR] Failures: 
[ERROR]   QuarkusLoggingUiTest.testChangeState2:42->checkGetResponse:58->checkGetResponse:70 
Expected: null
     but: was "TRACE"
[INFO] 
[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0

Showing that one passed, but the other does not.

This is because the first test made the state dirty and it was not cleared between tests.

kinbug triagwontfix

All 11 comments

@oscarfh have you try adding the @QuarkusUnitTest annotation on your test class?

@glefloch Oh, is there such a thing? I thought that QuarkusUnitTest was an extension, like used here (https://quarkus.io/guides/building-my-first-extension#testing-the-greeting-feature) and here (https://quarkus.io/guides/writing-extensions#testing-extensions)

My bad, I was confused with the QuarkusTest annotation.
BTW, I checked out your repo and tests a ok on my machine.

@glefloch Can you please confirm that you are on the quarkus-interdependent-tests branch?
Please notice that the automated build also fails: https://github.com/quarkiverse/quarkiverse-logging-ui/runs/1292569750?check_suite_focus=true

ah yes, it fails too on my machine. I haven't seen your link was on a different branch..

Maybe @geoand could help here?

@oscarfh can you give some context on what exactly you are trying to achieve?

Sure, @geoand.
The idea is writing this extension that allows me to call an endpoint to change the log level (see LoggerHandler.

I want now, to test this extension, and I will do that by:

  • Verifying the current log level, whether it is the expected (default) one
  • Change the log level by calling the endpoint
  • Verify whether the change had an effect

I have other tests, for instance, checking that I can get a specific logger, for this test, I:

  • Retrieve the logger
  • Verify whether the logger is configured as expected

The real test class can be found in the master branch, here.

*The problem is: if I use the same logger in both tests that I described here, the get test will fail, because the change test manipulated the logger. My expectation is that, because I am usingQuarkusUnitTest`, these tests are independent because the context has bean cleared between tests.

If you prefer, we can schedule a zullip chat or a hangout meeting to clarify.

I think this is just a logging specific problem, rather than a general one.

I don't think we actually want to fix it, as in general we want the logging settings to stay around, during shutdown we don't want to wipe out logging settings and have something go missing.

IMHO we can close this as a known limitation of @QuarkusUnitTest. If you really want to test this then use forkmode=always to get a clean JVM for each test.

I completely agree with @stuartwdouglas.

Although in general we do want @QuarkusUnitTest tests to be independent of each other, some things just make sense to keep around.
In addition to Stuart's suggestion of using forkmode=always, you can also configure Maven Surefire to use multiple executions - thus ensuring that the specific tests you want are executed in a different process.

@geoand Is this expected to be the case between test classes? Is there a way to force a "full shutdown" or clean the logger context?

I don't think we have something towards that

Was this page helpful?
0 / 5 - 0 ratings