Release Notes 0.16.0 | www.integrity-tf.org

Version 0.16.0

Integrity v0.16.0 comes with the following major changes from its predecessor, 0.15.x:

Integrity 0.16 compiles against Eclipse Neon, so you'll also need the corresponding dependencies. As always, there are pre-built packages with the dependencies on the download site as well as in the Nexus.
Performance improvements galore! This release has received a lot of performance-related improvements, which aim to drastically reduce overhead time on test executions in scenarios with large test script bodies. Among these improvements are:

Several tasks in the test runner startup phase are now parallelized, with the test runner automatically using the maximum number of processors on your system. This applies to both test script parsing (parallel parsing of several scripts) and global variable resolving.
Forks can now start up a lot faster than before, since they don't have to perform the whole initialization phase again, as it was before. They are instead injected with as much initial state as possible from the master process upon initial connection. This injection by the way includes the test scripts now - so technically, forks now don't even have to have access to the actual test script files anymore, because they don't need to read them from the disk again and again.
Forks also exit faster after they've performed their last action, especially in situations in which there's still a huge amount of test script actions to be performed afterwards. In such situations, forks had to do quite a bit of (useless) processing in pre-0.16 versions, just so they could exit gracefully. This is no more!
The entire remoting stack (that is, the protocol between master and forks as well as between the Eclipse Test Runner plugin and the actual test runner processes) has been switched to use Kryo now instead of the default Java serialization. Kryo's main selling point is - you guessed it - much better performance for object serialization/deserialization tasks. Note that this step breaks compatibility between the Integrity 0.16.x Eclipse Test Runner Control Plugin and pre-0.16 Integrity Runtimes! You thus need to update the plugins at the exact same time as the test runner!
The XSLT transformation has been optimized by switching from Xalan to Saxon, which in itself is already faster, but which also allowed me to remove an ugly post-processing kludge from the HTML output stream that slowed things down seriously, especially when writing larger output files of multi-megabyte size. XSLT processing is now multiple times faster in such cases - I measured a 4x-8x speedup in a larger test case!

- A performance logging module has been added, which you can use in your own projects to find out what Integrity is doing in those strange "silent" seconds. Just set the system property "integrity.runner.perflog" to "true" and you'll get performance timer data printed to stdout. (By the way, a new documentation page has been created that gives an overview over all system properties supported by the Test Runner!)
GitHub issue #135

It is now possible to define a suite as "single-run" suite, which means that it will only be executed once per test run - no matter how often it is referenced in a direct call ("suite aSuite") or indirectly via dependencies ("requires aSuite"). Actually, dependencies have a similar behavior, but they have the notion of "scope" which means that they are only not executed again while the execution context is within the dependency suite, for examples in suites called directly which also have the dependency in question. Once the suite is left that a dependency was executed for, its finalizers are run and if a later-executed suite calls for this dependency again, it would be invoked a second time. The new "single-run" suites differ in two ways from this: they do not "reset" their already-executed state, and the fact that a suite is a single-run suite is noted at the suitedef command and not at the place that's calling it:
```
single-run suitedef testSuite with
	// here comes stuff
suiteend
```
GitHub issue #134

There are now "inlined" suite invocations, which are a new tool to improve the clarity of your test result files while still being able to use all the features that suites have to offer regarding test structuring. In practice, there are quite often reasons to call a suite that don't really deserve the very pronounced way in which suite calls are rendered in the HTML test result page - for example you may just use a suite like a "function" in a programming language, putting a value into it, maybe executing two calls and a test and getting something in return, and in such cases you wouldn't even want to see that this stuff runs inside a suite in the end results. Similarly with forks - sometimes, just a few commands are to be run on a fork, so you put them into a suite and run that suite on the fork.
It's probably best to show a before-and-after example of this in practice, so here it is!
Before...

...and after:

Here is the script that was used:
```
suitedef asuite with		
	-- We do some important stuff here		
	inlined suite anotherLittleSuite on fork1		
	-- We do more important stuff here		
	inlined suite anotherLittleSuite		
suiteend
```
You can easily see the "inlined" before the actual suite call - that's all that is necessary. Oh, and setup as well as teardown suites are now always inlined - they are assumed to be a functional thing by default, because setting something up and tearing it down isn't technically "testing" but more a functional task that is necessary to prepare the stage for the actual tests, so that makes them prime candidates for this new feature!
GitHub issue #137

Breakpoints in the Eclipse Test Runner plugin are now "persistent" - they are automatically recreated on further test runs (at least if the execution step that they were placed on is found again in subsequent runs). Consequently you can now add and remove breakpoints when nothing is being executed as well. A new button has been added to easily clear all breakpoints, too.
GitHub issue #130
Parameterized constants now support "default" values - just add the desired default value between the constant name and the "parameterized" keyword (so effectively, you simply use the same syntax as with normal constants, just with an added "parameterized" afterwards). In earlier versions, constants could only either have a value defined in the test script or be "parameterized", but if they were the latter, the only possible default value was "null" which was assigned if the parameterized value has not been provided for a test run.
GitHub issue #123