As part my efforts to develop ucumate, I have created more tests. The tests are available as a JSON file and include publicly available code lists (such as the fhir-common codes list) as well as extensive edge case testing. The latter causes some problems for Ucum-java. Due to the ambiguity in the UCUM specification, there are some validation differences. These are explained here.
I have also developed drop-in replacement layer that implements the UCUMService interface defined here. The behavior to Ucum-java is really close, but some validation differences exist. For like 95% of the commonly used codes this is not a problem, just the edge cases behave slightly different.
I can also contribute the test suite back to this library but I am unsure what the best way is.
Should I convert the test cases to the existing XML test suite style?
And what about the validation differences?
ucum-tests.json
As part my efforts to develop ucumate, I have created more tests. The tests are available as a JSON file and include publicly available code lists (such as the fhir-common codes list) as well as extensive edge case testing. The latter causes some problems for Ucum-java. Due to the ambiguity in the UCUM specification, there are some validation differences. These are explained here.
I have also developed drop-in replacement layer that implements the
UCUMServiceinterface defined here. The behavior to Ucum-java is really close, but some validation differences exist. For like 95% of the commonly used codes this is not a problem, just the edge cases behave slightly different.I can also contribute the test suite back to this library but I am unsure what the best way is.
Should I convert the test cases to the existing XML test suite style?
And what about the validation differences?
ucum-tests.json