test: Adopt JUnit5

[manticore-projects]

• use Parametrized Tests where possible
• use Assertions where possible
• check for Throws/DoesNotThrow where possible

The main advantage is proper IDE support with executable tests (in Netbeans and IntelliJ) as well as parallel execution.

I still would like to suggest to:

1. move the testSpeed benchmarks into its own Benchmark package (possibly using PMD for micro benchmarking)
2. replacing any System.out by proper loggers (it is very noisy right now)
3. remove the ant build file (because ant is really dead)

Do let me know how you feel about that.

[flanglet]

Hey, thanks for the proposal.
Quick question: running the Entropy or Transforms tests from the command line now only run the speed test but no longer the correctness ones?
WRT to your suggestions:

1. Fine, but it looks like quite some work, also I do not want to add extra dependencies.
2. Seems like a good idea for the tests.
3. True, but I do not want to break anyone's workflow.

[manticore-projects]

Quick question: running the Entropy or Transforms tests from the command line now only run the speed test but no longer the correctness ones?

You can still run the Tests from the command line, e.g.:

cd kanzi/java

# run all tests of a unit
/gradlew test --tests io.github.flanglet.kanzi.test.TestCompressedStream

# run single isolated test only
/gradlew test --tests io.github.flanglet.kanzi.test.TestCompressedStream

1. Fine, but it looks like quite some work, also I do not want to add extra dependencies.

Not much work, especially since I would do that for us.
No additional hard dependency: PMD is like JUnit5 only an optional part of the toolchain, to be executed only when explicitly wanted.

Actually, the package even gets slimmer because you will get 4 JARs at the end:

1. one for the KANZI library only (w/o doc, tests and benchmarks)
2. one for the JavaDoc
3. one for the tests
4. one for the benchmarks
5. on for the sources

2. Seems like a good idea for the tests.

I agree and would convert that gradually. I want to keep the PRs small and encapsulated as possible so we have a chance to understand and digest.

3. True, but I do not want to break anyone's workflow.

Well, anyone who really wants to build it using ANT would use ANT just as a wrapper calling the Maven Build or the Gradle Build.
In my opinion, even a Makefile would be more functional than this ANT build at this point. But this is not the hill I want to die upon. We can always delete it later.

My main goal was to have Stable artifacts in Maven Central so this library becomes easier accessible and well known. (I love it so much for compressing my large SQL dumps!)