Added new module with samples of the Hazelcast test support.

[fcannizzohz]

We have updated the official docs (https://github.com/hazelcast/hz-docs/tree/main/docs/modules/test/pages) with content explaining how to use the Hazelcast test support classes. As a compendium to that, this is a project with some sample code showing how to use the classes in action.
It shows the test support classes in action for unit/integration tests for caches and streaming. Both in JUnit4 and JUnit5 flavours.

[fcannizzohz]

@JackPGreen thanks for the review - I believe I have addressed all your feedback

[JackPGreen]

Some optional nits from me but otherwise happy :)

[fcannizzohz]

Thanks @JackPGreen 👍

[JamesHazelcast]

Thanks for putting this together @fcannizzohz, it's a great addition to your documentation for testing in Hazelcast.

I note that very few of the provided Java files have javadocs, and none have copyright headers - these don't seem to be consistently applied across the code samples repo, but I think it's good practice and shows a high standard to include.

I also think we need to improve the consistency of how we recommend customers shutdown their HZ instances - if they're using one of our utility methods and they extend the test support class, it is handled for them. If they create their own factory, they should either use tearDown methods or try/finally blocks. I find the currently used approaches confusing.

[JamesHazelcast]

I don't see any references to HazelcastTestSupport in this example, beyond createHazelcastInstance() which is used in the above as well.

[fcannizzohz]

the example is meant to bring attention to testing of the execution of a listener and specifically the correct wiring/setup of the listener in the HzOrderService. Having to produce the entire class here is a distraction. I am adding a note with a link to the entire test for reference.

[JamesHazelcast]

My comment was mainly around this sentence's setup of discussing HazelcastTestSupport, and specifically stating it's used in the code below - but then it's not referenced in any special way. It's not a blocker for me.

[JamesHazelcast]

Same as previously mentioned - do we really want to do these before/after steps for each test as opposed to once for the class?

[fcannizzohz]

It should really be a test user concern whether to have a static cluster shared between tests or not. The primary concern in unit testing is test isolation so that all tests can run in any order and in parallel.
The best way to guarantee this behaviour is by having cluster setup/teardown per test. Furthermore, the whole spinup/shutdown loop is fast because of the mock network, making this pattern adoption desirable.

Also, this codebase is not about documenting how to write unit tests, but to provide correct patterns of utilisation of the test API.

My point here is that we're showing a valid usage of the API; whether this is the best way for the specific case, it's down to the user.

[JamesHazelcast]

I understand where you're coming from, and I agree that there's various different valid approaches/styles to test framework layout. In this case however, we're creating a lot of factories when a factory is intended to be created once and reused, which isn't best practice. I believe this approach is safe because of the default JUnit 5 execution policy, as each test method gets a new instance of the class, but if the policy were changed to non-default, then these resources would bleed between tests if executed in parallel, and shutting down the factory after test 1 could destroy instances in test 2.

Again, not a blocker for me here, but I do have some light concerns about this representing our best practices.

[fcannizzohz]

Understood - if the factory keeps state that's not thread local it may be a problem or something we should fix. Even if the factory is class scoped the problem would not disappear.

[fcannizzohz]

@JamesHazelcast thank you for the feedback - I think I have addressed most of it and left comments in response to your questions. I have also added javadocs to all files.

[JamesHazelcast]

Thanks for putting this together @fcannizzohz - a couple of minor comments remain, but none are blockers for me, so I will approve in advance now.