How to configure vertx-jnit5 to run tests in a VertxThread?

[Matthew Adams]

Hey all

I'm using vertx-junit5 and noticed that no test methods are being run in a VertxThread, which causes Vertx.currentContext() to return null, along with an ensuing NullPointerException (I'm dealing with some inherited code that assumes operation in a VertxThread). How do I configure @ExtendWith(VertxExtension.class) to cause tests to run in a VertxThread instead of a vanilla java.lang.Thread?

Thanks,

Matthew

[Julien Ponge]

Hi,

Can you show us an example of how you are using it?

- Julien

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/dcd1fef2-96ca-4ee4-b6c2-c2a8863582f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Adams]

Here ya go:  https://github.com/vert-x3/vertx-junit5/pull/43

[Julien Ponge]

Ok so let me make a review.

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L32

It fails because the test method is being executed on the JUnit 5 executor thread. That’s to be expected.

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L57

Because you use Vertx context injection, you do not have to do the awaitCompletion call. This is being done by the test context for you.

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L46

Why is there anything to synchronize?

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L38

It is not clear (and also in the rest of the test fixture) what you are trying to achieve.

Again the design of testing async code (and that is the same for vertx-unit with JUnit 4) is that:

1. the test method thread is that of the test harness runner,

2. async operations (e.g., vertx.setTimer(…)) have their callbacks running on event loop threads,

3. the test context is here to put the test harness runner on hold until stuff executing in other threads (event loops, workers, etc) report success or failure.

Hope it helps

- Julien

[Matthew Adams]

Explanations inline below.

On Friday, June 8, 2018 at 3:58:47 PM UTC-5, Julien Ponge wrote:

Ok so let me make a review.

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L32

It fails because the test method is being executed on the JUnit 5 executor thread. That’s to be expected.

I'm asking that you consider allowing a user to configure the VertxExtension to run the tests on a VertxThread such that Vertx.currentContext() does not return null.

 

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L57

Because you use Vertx context injection, you do not have to do the awaitCompletion call. This is being done by the test context for you.

Understood.  Removed.

 

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L46

Why is there anything to synchronize?

That was unintentional, copied from the dumb code that we're forced to deal with.

 

https://github.com/matthewadams/vertx-junit5/blob/f14c9f3cc8532c190d94df7035d43ba890b70e83/src/test/java/io/vertx/junit5/RunOnVertxThreadTest.java#L38

It is not clear (and also in the rest of the test fixture) what you are trying to achieve.

* Class "SimulatorOfDumbCodeOutOfOurControl" is a minimal reproduction of the code we are calling that is out of our control, meaning we can't change it.

* The crux of the issue we're having is illustrated at the first line of method getWebClient():  WebClient webClient = Vertx.currentContext().get(WEB_CLIENT_ID)

Make more sense?

--matthew

PS: I pushed changes to my personal repo's branch, but they don't appear to be showing up yet in the PR.  Prolly StupidUserException.

[Julien Ponge]

Did you look at https://vertx.io/docs/apidocs/io/vertx/core/Vertx.html#runOnContext-io.vertx.core.Handler- and https://vertx.io/docs/apidocs/io/vertx/core/Vertx.html#getOrCreateContext-- ?

BTW what are you trying to do with WEB_CLIENT_ID? Just in case: a context does not have ThreadLocal semantics, any data that you put here is for a whole event loop (which may handle an arbitrary large number of unrelated events such as 10_000 network requests).

- Julien

--

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/e97bfcb8-1664-41a6-897f-be498d85ff34%40googlegroups.com.

[Matthew Adams]

On Friday, June 8, 2018 at 4:23:55 PM UTC-5, Julien Ponge wrote:

Did you look at https://vertx.io/docs/apidocs/io/vertx/core/Vertx.html#runOnContext-io.vertx.core.Handler- 

Didn't see that one!  That did the trick.  This test now passes:

@ExtendWith(VertxExtension.class)

@DisplayName("Configure extension to run tests in a VertxThread")

class RunOnVertxThreadTest {

  @Test

  public void ensureVertxThread(Vertx vertx) {

    vertx.runOnContext(event -> {

      assertTrue(Thread.currentThread() instanceof VertxThread);

      assertNotNull(Vertx.currentContext());

    });

  }

}

and https://vertx.io/docs/apidocs/io/vertx/core/Vertx.html#getOrCreateContext-- ?

Yeah, saw that, but, again, we don't have control over the dumb code I gave a sample of, so this was a no-go.

 

BTW what are you trying to do with WEB_CLIENT_ID? Just in case: a context does not have ThreadLocal semantics, any data that you put here is for a whole event loop (which may handle an arbitrary large number of unrelated events such as 10_000 network requests).

We're not doing anything with it.  It's part of the dumb code over which we have no control.  Good to know, though.

Thanks for your help.  Problem solved!  Perhaps this would be worth adding this scenario to the vertx-junit5 documentation.

I went back to https://vertx.io/docs/vertx-junit5/java, the Vertx JUnit 5 doc page, and noticed that the code example at https://vertx.io/docs/vertx-junit5/java/#_a_test_context_for_asynchronous_executions shows the use of assertTrue(context.awaitCompletion(...)).  It's only later, between the two code blocks at https://vertx.io/docs/vertx-junit5/java/#_test_methods, is it mentioned that you don't need to await context completion.  I think that's how I missed it.  Perhaps it's worth updating all of the code samples on that page to start out with JUnit 5 integration (since that's what the page is supposed to be about), and ensure code samples use the best practices like using VertxExtension and not having to manually await context completion.

Thanks for your help.  I'm now off & running.

--matthew