Release Notes 20.0.0 | www.integrity-tf.org

Version 20.0.0

Integrity v20.0.0 comes with the following major changes from its predecessor, 19.x:

Integrity is now built against Eclipse 2020-06 and Xtext 2.22.
Fixture methods can now (optionally) provide localized description texts! There is a new attribute "i18nDescriptions" and annotation @I18NDescription in the @FixtureMethod annotation that can be used to provide an array of description texts for various locales. When running tests, you can provide the test runner with a test result locale string (via a new command line parameter) and the runner will use the matching localized description texts if possible (it will of course fall back to the default ones without a locale if it doesn't find a match). This allows you to make test results even more readable, especially in projects with a non-English main project language, since the vast majority of textual content in test results is effectively generated from fixture method descriptions!
The Eclipse test runner plugins' scrolling behavior on the test results pane has been improved, especially when displaying large amounts of text with long lines in test results (they will now linebreak and won't force the entire test result pane to horizontally scroll anymore) or when displaying images in extended fixture results (these will now be scaled down such that they fit into the width of the test result pane if necessary, and only when clicking on them they will be displayed at full original resolution, which then of course mandates horizontal scrolling).
The Integrity script editor in Eclipse has gained more sophisticated support for managing imports!
- There is now an "organize imports" command which works similar to the one for Java:
  - Imports are sorted alphabetically
  - Duplicate imports are eliminated
  - Unused imports are eliminated (only if "warn about unused imports" is enabled).
- Additionally, a new warning was created that warns about unused imports in Integrity scripts, offering a quick fix to remove the import. This feature is configurable via preferences (enable/disable, default is enabled).
- The organize imports action can either be triggered manually (like formatting), via keyboard shortcut, or it can be automatically run on file save (configurable; is enabled by default). The feature only works as intended if all the imports are collected at the beginning of a file and NOT subdivided by comments (anything other than comments isn't possible between imports anyway). Comments before the first import statements are possible, but not between import statements.
- In addition, a feature allowing to quickly "shorten" imported entities to a configurable number of packages (and to generate a matching import statement if not already present) has been implemented. The depth of packages for partial qualification (= the number of package levels NOT to be imported, but to be explicitly stated) can be configured via preferences; by default it is set to 100, which effectively means that this feature is disabled entirely. If enabled (by configuring the intended depth, for example 1 or 2), the feature will generate INFO level hints for occurrences of imported entities being used with more package levels states at the point of use than the configured number, and these hints have an associated quick fix allowing to quickly shorten the number of package levels to the target number and generate the necessary import (if not already present).
Keyboard shortcuts (configurable through normal Eclipse preferences) have been added for the following actions in the Integrity Test Runner view:
- Run selected Integrity test launch config (run chosen config + autoconnect)
- Debug selected Integrity test launch config (same as run, but in debug mode)
- Terminate running Integrity test
- Connect to an already-running Integrity test runner
Support for regular expression matching of test results has been added! Instead of an exact match, which was the only supported kind of match until now (and of course the possibility to write a CustomComparatorFixture in order to programmatically provide your own matching logic), the regular expression match can now be transparently used practically anywhere to match test results. Just provide your regex string enclosed in tildes, as shown in the following example:
```
// This fixture just echoes the given string, and the comparison doesn't perform
// an "equals" comparison in this case, but a regular expression match. It will
// search for "this" in the string and the test will succeed if it finds that
// substring anywhere.
test echoStringTest string: "Echo this!" = ~this~

// This one will also be successful, but it matches the entire string to the given
// regular expression (which is anchored at the beginning with ^ and end with $).
// It also uses the \s character class to match the space.
// Generally you may use all the features of Java's regular expression syntax
// as documented for the "Pattern" class:
// https://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html#sum
test echoStringTest string: "Echo this!" = ~^Echo\sthis!$~
```
- In addition to the regular expression matching, you can now also use the java.util.regex.Pattern class as an input parameter type for your fixture methods! The user of your fixture can then provide a regular expression not for matching, but as an input into your fixture. You will get the compiled Pattern object in that case, and Integrity's included syntax validation will have already validated that what the user entered is actually a valid regex at edit time!
- When entering regular expressions in Eclipse, they will of course be immediately validated and erroneous expressions will be highlighted instantly. Also, regular expressions can be used practically like Strings, meaning that you can assign them to constants for example and then use those constants as expected results for fixtures, or as input to fixtures.
(v20.2.0+) The new "empty" keyword allows to test for empty lists/collections/arrays! This fixes a long-standing deficiency: due to the Integrity DSL not using any kind of list delimiter (such as square brackets for example), it was not possible to easily express the expectation of an "empty" list (which clearly is something different than a null value). To remedy this, a new keyword "empty" allows to state the expectation of an empty list. Using this keyword works with immediately-returned arrays or other collections, as well as with arrays/collections returned as part of a Java Bean or a map and tested within a nested object. Such an emptyness test looks like this (the fixtures return either an empty list or an empty list wrapped in a bean):
```
// Returns an empty list
test echoEmptyListTest = empty

// Returns an empty list within a Java Bean
test echoEmptyListInBeanTest = {
        emptyListAttribute: empty
    }
 
```