unitsofmeasurement / unit-tck Goto Github PK

Release 2.1.1 after changes from #40

Add tests for the isEquivalentTo() method in Unit and Quantity.

Update dependencies like lib and RI to the latest version. Also update parent POM to the latest version before releasing 1.0.1

As the groups property of the @test annotation expects a String array and does not work with enum values, it is best to give up the Group enum and use those string constants directly.

The Profile enum shall remain because it is used in a different place.

Executing mvn dependency:tree on the TCK gives the following output:

tech.units:unit-tck:bundle:2.1.2-SNAPSHOT
+- javax.measure:unit-api:jar:2.1.2:compile
+- tech.units:indriya:jar:2.1.2:compile
|  +- tech.uom.lib:uom-lib-common:jar:2.1:compile
(…snip…)

This is an issue when we want to test any implementation other than Indriya, because the ServiceLoader used by the TCK can randomly pickup Indriya instead of the implementation that we want to test. It has happened to me today when trying to run Seshat tests. I got confusing test failures until I understood that tests specifically designed for Seshat were running with Indriya implementation.

As a workaround, importing the TCK in a project as below seems to work:

    <dependency>
      <groupId>tech.units</groupId>
      <artifactId>unit-tck</artifactId>
      <version>2.1.1</version>
      <scope>test</scope>
      <exclusions>
        <exclusion>     <!-- Avoid possible interference with the implementation under test -->
          <groupId>tech.units</groupId>
          <artifactId>indriya</artifactId>
        </exclusion>
        <exclusion>     <!-- MutabilityDetector uses an older version than the one inherited from JUnit. -->
          <groupId>org.hamcrest</groupId>
          <artifactId>hamcrest-core</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>tech.uom.lib</groupId>
      <artifactId>uom-lib-common</artifactId>     <!-- Was a transitive dependency of excluded Indriya. -->
      <version>2.1</version>
      <scope>test</scope>
    </dependency>

But if excluding Indriya does not prevent the tests to work, why the TCK depends on Indriya? If this is used for testing the tests, then could the Indriya dependency be declared with <scope>test</scope> in the TCK project? It would make much simpler to import the TCK in another project.

The QuantityTypesTest class has some JavaDoc that seems copied from another class. It should be changed to what each method does.

While the current approach in the POM to JPMS works, the module-info is placed in the (Java 8 backward compatible) default module. This confuses the compiler and breaks the build if the TCK is run with Java 8:

[INFO] �[1m------------------------------------------------------------------------�[m
[INFO] �[1;31mBUILD FAILURE�[m
[INFO] �[1m------------------------------------------------------------------------�[m
[INFO] Total time:  2.735 s
[INFO] Finished at: 2023-10-04T23:46:15+02:00
[INFO] �[1m------------------------------------------------------------------------�[m
[ERROR] Failed to execute goal �[32morg.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile�[m �[1m(default-compile)�[m on project �[36munit-tck-usage-java8�[m: �[1;31mFatal error compiling�[m: invalid flag: --release -> �[1m[Help 1]

If Java 9 or above are used, it works fine.

For API or Indriya RI, the module-info is located in META-INF/versions/9 and higher, so the default JDK won't pick them up if it is Java 8. This should be possible with the AntRun plugin, as that is easier than the ToolChain plugin used by the RI.

MR2 could be the last version to still support Java 8, but with the new SI prefixes and Java 8 still around till at least 2030, the current MR still supports it as the minimal Java version.

Fixing https://github.com/unitsofmeasurement/unit-tck/security/dependabot/1

The ServiceConfiguration can be customized by a TCK test suite using the standard Java Service Loader mechanism, but it is not so well documented as are command line arguments, etc.

Upgrade TestNG to Version 7

Building the TCK when JavaDoc is generated there are several warnings or errors. None break the build but adding necessary tags or information as well as changing some links or tags this can be improved and the number of warnings or errors reduced to a minimum.

While it should be possible to override ServiceConfiguration.getPrefixClasses, a vast majority of implementations may be happy with the two built-in prefixes of the API, therefore ServiceConfiguration should get a default method,

Allowing to configure the TCK test suite via ServiceConfiguration in a module-info instead of META-INF:

module com.service.provider {
    requires tech.units.tck;
    provides tech.units.tck.util.ServiceConfiguration with com.service.provider.MyServiceConfig;
}

• Maven POM and settings.xml, see https://central.sonatype.org/pages/apache-maven.html
• Project Settings: Update CI_DEPLOY_PASSWORD for Sonatype/OSSH
• Dependencies to Test Audit Utils, they seem broken without Bintray, see jboss/jboss-test-audit#8

See unitsofmeasurement/uom-parent#24

JUnit 5 offers many new features, inspired by TestNG or otherwise. Could the JSR 385 TCK benefit from some of them?

A future version of the TCK may also include SigTest or any other suitable tool from the JDK.

Include information about the JDK that's used to run the TCK, as the Java versions change massively and it is also interesting to know, which OpenJDK distribution was used where the information is available.

Add signature tests for new methods added by unitsofmeasurement/unit-api#191

There could be some minor refinements in test documentation, e.g.
"Test method: 4.2.1.2.1 Ensure the divide() operation is implemented."
might say
"Test method: 4.2.1.2.1 Ensure the divide(Unit) operation is implemented."
instead, to align with other method tests.

In https://github.com/unitsofmeasurement/uom-tools Airline is used for the CLI. Could we also use that or even JShell? (would require Java 9 as minimum version to run the TCK)

The following issue occurs while building:

System

• macOS Mojave 10.14.4
• Java 11

This is a prerequisite for #20 .

Based on unitsofmeasurement/unit-api#184 TCK tests for Unit should be adjusted to the renamed method.

Update from the old Injection JSR to Jakarta Inject, 1.0 or better 2.0

JBoss Test Audit released https://github.com/jboss/jboss-test-audit/releases/tag/1.1.4.Final about a year ago. The TCK should be upgraded to use the latest final version.

As an API level method like compound() or mix() was disregarded by unitsofmeasurement/unit-api#190 the TCK shall be reviewed and adjusted where necessary.

Add a TCK test for the recently added getUnit(String string) method in SystemOfUnits.

The new version of the specification got a few chapters reordered or elements like Prefix introduced to existing ones. This affects the numbering of test cases which must be addressed in the TCK.

Right now the system properties start with tec.units.tck. They should be refactored to tech.units.tck like the package or GroupId names.

A new test case for QuantityFormat is needed similar to those for UnitFormat.

The FundamentalTypesTest already checks for prefixes,

The test description

Ensure at least one Prefix implementation is available/registered.

Should be refined, because the API already contains the two most common Prefix implementations.
In addition to rephrasing it as "at least two" we may consider a type-check that MetricPrefix and BinaryPrefix are always part of that list.

In the ServicesTest for SystemOfUnitsService the method returning a Set of Prefix may also check, that MetricPrefix and BinaryPrefix are always part of the Set. And the minimum size is 2.

The issueManagement tag of the POM still points at java.net JIRA. As this system will be shut down by April 29, 2017 point to this GitHub issue tracker instead.

If a UnitFormat implementation extends java.text.Format (which historically many formatters do, also in JSR 275) a method with the same name but different signature in the superclass gets picked up first causing 1 test to fail, see https://groups.google.com/forum/?hl=en#!topic/units-dev/8wk2a7dctUo

See #43 (comment)

Also create GH-Pages for the TCK project similar to RI or API.

Reduce the errors and warnings for JavaDoc generation.