You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Consider implementing
AbstractLanguageDetectionAccuracyReport
using JUnit's@TestFactory
.Advantages:
AbstractLanguageDetectionAccuracyReport
implementationsInstead could have a
@TestFactory
which creates a JUnitDynamicContainer
for each language, containingDynamicContainer
for the test variants (word, sentence, ...) and thenDynamicTest
for each input. InAbstractLanguageDetectionAccuracyReport
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:
However, could consider adding system properties or similar which determine the detector and language, similar to the current existing logic in
build.gradle.kts
.The text was updated successfully, but these errors were encountered: