JUnit5 integration

[ashleyfrieze]

There are cases when the lambda-based wrappers don't quite hit the mark.

For example, let's say we're using the @SpringBootTest plugin, and our SpringContext takes environment variables as part of its input. This might be resolved by something like:

class MainTest {

   // initialise some environment variables somehow

   @Nested
   @SpringBootTest
   class SpringTest {
   }
}

In the above, it's not possible to run the inner test within a withSystemLambda( () -> {}) construct.

I have a solution for this. There could be a JUnit5 extension which does the necessary setup/teardown, rather than the equivalent JUnit4 Statement or try/finally of the lambda approach.

I've hacked a working example of this together. As the methods to do setup/teardown within this project are private, my hacked version does some weird stuff (with the JUnit4 version of system rules).

If there were to be such a JUnit5 plugin, raised as a PR, which project would it belong in? If it were to be done without hacking, some of the setup/teardown methods of this codebase would need to be exposed - to the plugin at least.

@stefanbirkner what do you think about the possibility of introducing this extension?

[stefanbirkner]

@ashleyfrieze Thank you for explaining your use case. I suggest to use JUnit Pioneer's support for environment variables or extend it if it doesn't fit your needs.

[ashleyfrieze]

@stefanbirkner it looks like JUnit Pioneer starts with the assumption that environment variables need setting to static values. The challenge I'm facing is that environment variables I need to set are based on dynamic values - for example a random port number, or the address of some other generated resource.

If system-lambda were to make its set up and teardown methods public, I wouldn't have to hack around it.

[stefanbirkner]

System Lambda uses the execute around idiom. Therefore it does not have independent setup and teardown methods. Of course you can create such methods based on System Lambda's code. Feel free to create a JUnit Lambda extension by copying System Lambda's code. Mentioning System Lambda as the source of the code would be nice but is not mandatory.

[ashleyfrieze]

Hey @stefanbirkner - I appreciate the design pattern you're using. I also thank you for the permission to reuse your source code. It seems a shame, though, to fork off yet another project when there is a way to allow both models, while favouring the execute around model.

Let's imagine we created a interface:

public interface Resource {
   void setUp();
   void tearDown();
}

Let's also look at how most of your code is structured in terms of that interface:

void withSomeResource(Runnable runnable) {
   try {
       setUp():
       runnable.run();
   } finally {
       tearDown();
   }
}

While we could keep the execute around idiom, with the introduction of the above interface to your solution (hiding the way that setup and teardown must be executed), then we could even generalise the execute around idiom, as well as safely expose the manual setup/teardown to libraries that needed it. That could allow more of a JUnit5 native plugin approach to be added as well as other use cases for people.

Similarly, if we made sure all the setters for your objects were fluent, then it would allow more flexibility.

I wanted to discuss this before offering a PR, and I suspect you may still be closed to the idea. However, I thought I'd suggest it one last way before going off and doing my own thing. It's often better to contribute back to a project, than to take its good ideas and use them independently.

[ashleyfrieze]

I forked a new repo https://github.com/webcompere/system-stubs - it solves the issues I was facing.