After two bugfix releases a new feature release. On November 19th Christoph create the Release for OpenFastTrace 2.1.0.
Feature-wise we are happy to announce an improved HTML report.
Sonar checks are now up and running again and the last JavaDoc errors have been rooted out.
We also fixed the deep coverage detection which was pointing upwards instead of downwards in the tracing chain. As a consequence we had to rework link loop detection, which acts a lot smarter now than before.
In a recent blog post I wrote about the migration from JUnit4 to JUnit5 as unit testing framework.
Even though the version number increase from 2.0.1 to 2.0.2 might not look like much, it is in fact a major milestone for OpenFastTrace, since from here on writing tests will be faster and more efficient.
Can you accumulate technical dept, even if you regularly clean up your sources meticulously? A short while ago I would have said that this is possible but unlikely. That was before I started taking on the migration of all of OpenFastTrace‘s unit tests from JUnit4 to JUnit5.
This release is a big step forward. One new feature, a few small fixes and a lot of code improvements that gives us a much cleaner and more uniform API, better test coverage and lower overall complexity.
But a new API also means we had to break backward compatibility to achieve something that the existing API would not allow since it had a separation of report and export mode: you can now reuse an import that already ran to create both reports and exports from it without redoing the import.
Today we released version 0.4.0 of the OpenFastTrace Gradle plugin. This is the first version that can be considered production ready. It was successfully integrated into a real life commercial project using the following features:
Software architecture design (Swad) imported as a dependency from a maven repository Software detailed design (Swdd) written in MarkDown Coverage tags in code (long format) for item types src, utest and stest Filter requirements from Swad, Swdd and Code using a artifact type filter Filter Swad requirements relevant for the project using a tag filter Generate a tracing report in text format containing failure details Additionally, to the report we export the requirements in Specobject format that can be delivered to integration for creating an overall tracing report Only minor adaptions were required and OFT works in parallel to the proprietary tracing tool.