Version 0.15.0

Integrity v0.15.0 comes with the following major changes from its predecessor, 0.14.x:

• Integrity now compiles against Eclipse Mars! This also means that you'll need at least the Eclipse Mars runtime dependencies if you want to use Integrity 0.15. I know, that sounds like work, but I've got a goodie: the number of dependencies that are packaged within the Mars 0.15 standalone execution dependency packages (see the Download page for those!) has been greatly reduced - basically it's been almost cut in half :-) this means fewer additional jars!
  
  
• Conditional fixture description text parts can now be nested! So you can now write stuff like {aParam?aParam was supplied {anotherParam?and anotherParam as well}{^anotherParam?but not anotherParam}} to be even more clean and decisive in your human-readable fixture descriptions.
  
  
• A new command 'assign' was added which allows you to assign a value to a variable - without having to call a fixture. This of course does not only work with fixed values, but also with contents of other variables, operations etc.:
  
  

  assign "Foobar" -> myFirstVariable
  assign (otherVariable * 2) -> mySecondVariable

  
  
  

• The new keyword 'checkpoint' may be added in front of test invocations to make them "checkpoint tests". Such a "checkpoint test" will abort further test execution immediately in case it fails (= red result color)! You can use this feature to prematurely abort long test sequences in case of failures on highly critical tests, after which further execution may not make any sense. The test result file is of course written normally (up to the point of test abortion) and states the reason for the premature end of execution clearly. And: this feature works just fine with forks (meaning: it kills them :D)! It also kills any processes registered by fixtures with the ProcessTerminator service, so if you start your own processes within fixture invocations (such as application servers), you should be fine, as long as you properly register them with the ProcessTerminator (which you can have injected into fixture instances via Google Guice using the @Inject annotation).
  
  
• In case of tabletests which have "common" parameters (those that you specify just once, above the table, which are then valid for all the lines), these parameters will now be displayed separately in the result HTML to reduce the clutter in the per-line results, effectively reducing the width of the result table and improving readability. It doesn't make much sense to print the same value over and over again for each line, doesn't it? ;-)
  
  
• Default values can now be specified for suite parameters. These defaults are used if a suite invocation does not supply a value for a particular parameter. It works like this:
  
  

  suitedef myTestSuite gets aFirstParameter by default "abc" aSecondParameter by default "cde" with 

  
  
  

• It is now possible to define "return parameters" for suites, which work basically the other way round than input parameters. You can use them to return data from within suites to the calling suite. Previously this was already possible via variables defined on package level, but the new return parameters are much more concise and easier to understand. Here is a simple example with two returned values:
  
  

  packagedef mypackage with
  
      suitedef asuite with        
          variable myValue1
          variable myValue2
  
          suite bsuite outputValue1 -> myValue1 outputValue2 -> myValue2
          call echoCall echo: myValue1 // this will echo 123
          call echoCall echo: myValue2 // this will echo 456
      suiteend
  
      suitedef bsuite gets inputValue returns outputValue1 outputValue2 with  
          assign "123" -> outputValue1
          call echoCall echo: "456" -> outputValue2   
      suiteend
  
  packageend

  
  
  

• The new optional fixture class interface "ResultAwareFixture" allows for performance optimizations in heavily-used, complex fixtures which might burn quite some CPU cycles to provide a lot of (named) result values, although maybe just one or two are actually checked in the test script. By implementing this interface, a fixture instance will be notified ahead of the actual fixture method call about the actually-checked result values, providing the opportunity to omit some work in the fixture call.