Consider implementing AbstractLanguageDetectionAccuracyReport using JUnit's @TestFactory.
Advantages:
- Reduces a lot of code duplication which currently exists for all
AbstractLanguageDetectionAccuracyReport implementations
Instead could have a @TestFactory which creates a JUnit DynamicContainer for each language, containing DynamicContainer for the test variants (word, sentence, ...) and then DynamicTest for each input. In AbstractLanguageDetectionAccuracyReport it would then only be necessary to define the list of languages to test (or all?), and then automatically get their language code and the corresponding test data.
Disadvantages:
- Might make merging upstream changes lightly more difficult (?)
- Cannot easily run tests for individual languages anymore
However, could consider adding system properties or similar which determine the detector and language, similar to the current existing logic in build.gradle.kts.
Consider implementing
AbstractLanguageDetectionAccuracyReportusing JUnit's@TestFactory.Advantages:
AbstractLanguageDetectionAccuracyReportimplementationsInstead could have a
@TestFactorywhich creates a JUnitDynamicContainerfor each language, containingDynamicContainerfor the test variants (word, sentence, ...) and thenDynamicTestfor each input. InAbstractLanguageDetectionAccuracyReportit would then only be necessary to define the list of languages to test (or all?), and then automatically get their language code and the corresponding test data.Disadvantages:
However, could consider adding system properties or similar which determine the detector and language, similar to the current existing logic in
build.gradle.kts.