Unit Tests

[CryptoMorin]

There are currently some issues with the unit tests that must be solved, most of them has to do with Maven. Also, some test related classes are left hanging around intentionally just in case they are needed in the future.

Right now there is a master profile tester which handles tests in general, and subsidiary profiles for running the unit tests on different Minecraft versions (named after the minor version 18, 17, 16, etc.)
So you can just run these tests with a simple Maven command: mvn clean package -Ptester,18

The first problem is that running these tests for lower versions like 1.16 won't work because surefire will use 1.16 jar to compile and test.
This will obviously fail because the XSeries library is designed to be compiled on the latest version and handle older versions during runtime.
I need to find a way to compile the tests using the latest version of Spigot, but test/run them using a lower version. I tried playing around with options like <dependenciesToScan> without luck.

Another insignificant issue is that I can't find a way to run all these profiles one after another automatically to test the library for all the versions.

And the last abomination is this. Without this delay the server won't completely load:

XSeries/src/test/DummyAbstractServer.java

Line 165 in 7477ef5

Thread.sleep(2000L);

[portlek]

The first problem is that running these tests for lower versions like 1.16 won't work because surefire will use 1.16 jar to compile and test.

i guess separating modules in terms of version could be help for this situation.

[rbluer]

Here is an idea about why the thread.join() is not working as expected.

Since thread.start() is not blocking and does not wait for the VM to actually spawn and start a new thread, it could be that when the vm initially hits the thread.join() it is not recognizing that thread is running yet, and therefore it does not block to await for the termination of the thread's run function. In the api docs, it does not explain what the behavior is if join is attempted on a non-running thread; if it just passes through, then it could explain the behavior that you are seeing.

Perhaps even a slightest delay after the start could allow join to finally block?

    thread.start();
    System.out.println("post-start");
    Thread.sleep( 50L );
    System.out.println("pre-join");
    thread.join();
    System.out.println("post-join");

Such that "Done!" should appear in the logs between "pre-join" and "post-join".

Might be able to get by with a value of less than 50 ms, such as 5 ms or even less, or it may need to be more. Personally, I'd probably bump that up to a higher value to accommodate slow/old hardware/vms when using it in a real unit test environment. I just wanted to illustrate with the 50 ms that its probably only needing a very short sleep time to give the vm a chance to create and get the thread started.

Not sure it this is exactly what is going on, but I just thought I'd throw my idea in to the ring. ;)
Blue

PS... My project has been using XSeries for well over a year now, but it is not included in any of your dependencies due to limitations of the use of gradle, of which is not supported in git's dependency reporting. Anyway, this is an excellent resource that has allowed me to scrap tons of old internal code "trying" to deal with block compatibility. Since the project is over 7+ years old, it became a nightmare to support newer blocks, especially with the flattening. So XSeries has really allowed me to focus on the plugin, and not the blocks, which is greatly appreciated! Thanks! :)