Proof of concept for using unit test framework

[cyrille-artho]

We would like to use a unit test framework for most (all?) tests, to abolish our own test runner, and to allow parallel testing.
First, a proof of concept is needed that shows how two or three tests run inside such a framework and possibly interact because static fields are not reset.
This may in turn require changes in Modbat's configuration handling or even beyond.

[cyrille-artho]

In 3.3, build.gradle is now set up with support for ScalaUnit (commented out):

//    classpath "gradle.plugin.com.github.maiflai:gradle-scalatest:0.23"
//    testCompile 'org.scalatest:scalatest_2.11:3.0.1'
//    testRuntime 'org.pegdown:pegdown:1.4.2'
//apply plugin: "com.github.maiflai.scalatest"

Uncommenting these lines will enable "./gradlew test" with ScalaUnit.

I would like to replace some test cases with ScalaUnit, so multiple tests can be run in parallel and without restarting the whole JVM. Example from bin/test.sh:

APP="scala -cp build/modbat.jar modbat.config.ConfigTest"

run 0 $APP

This results in:

> scala -cp build/modbat.jar modbat.config.ConfigTest
This is a test
for the splash screen

This could be done by rewriting config/src/main/scala/modbat/config/ConfigTest.scala as a ScalaUnit test in config/test/main/scala/modbat/config/ConfigTest.scala:

package modbat.config

import org.scalatest._

object ConfigTest {
  def testCtor(args: Array[String]) {
    c = new ConfigMgr("ConfigTest", "[FILE]", new TestConfiguration(),
			new Version ("modbat.config"), true)
    c.setSplashScreen(List("This is a test", "for the splash screen"))
    c.parseArgs(args)
  }
}

class ConfigTest extends FlatSpec with Matchers {
  "ConfigTest" should "run normally" in {
    ConfigTest.testCtor(Array()) // no arguments
  }
}

1. The code above has not been tested, so it may not compile or run correctly until small syntax problems are fixed.

2. With ScalaUnit, the output will appear in the console; we want to redirect this to a string, and in some cases parse it and check some of its contents. For the redirection, see:

https://stackoverflow.com/questions/4183408/redirect-stdout-to-a-string-in-java

3. We want to check if some key elements in the string are present and in the right format. In some cases, this can be checked by verifying certain lines in the output; in other cases, we want to redirect the output to a file and compare that against a previous run, as done now by bin/test.sh.

[cyrille-artho]

There is a better way to redirect stdOut and stdErr, as used by Modbat.scala:

    Console.withErr(err) {
      Console.withOut(out) {
        ...
      }
    }

"err" and "out" have to be PrintStreams that are set up for redirection. See
https://www.scala-lang.org/api/2.12.0/scala/Console$.html, "IO redirection".

At first, we probably want to use two ByteArrayOutputStream instances for err and out, respectively. This will augment and replace the two lines "System.setOut" (for out), and also support stderr redirection.

In a next version, we could provide a front-end to tests that use main in the current version, and redirect the output to a file in the same way as it is being done in bin/test.sh now.