feat(jans-fido2): add unit tests for Fido2UserMetrics computed logic

[imran-ishaq]

Is your feature request related to a problem? Please describe.
Fido2UserMetrics (jans-fido2/model/src/main/java/io/jans/fido2/model/metric/Fido2UserMetrics.java) is the per-user ORM entity backing every FIDO2 user-adoption metric stored under ou=fido2-user-metrics,o=jans. Unlike the earlier DTOs, this class carries real computed logic that downstream services and the REST analytics endpoints depend on:

• incrementRegistrations(boolean), incrementAuthentications(boolean), incrementFallbackEvents() — counter mutations with side effects on lastActivityDate/lastUpdated.
• getRegistrationSuccessRate(), getAuthenticationSuccessRate(), getOverallSuccessRate(), getFallbackRate() — null-safe ratio computations that must protect against divide-by-zero (otherwise Double.NaN / Double.POSITIVE_INFINITY leak into stored aggregates and JSON responses).
• updateEngagementLevel() — threshold-based bucketing into HIGH (≥50 ops), MEDIUM (≥10), LOW (otherwise). Off-by-one mistakes at the boundaries silently re-bucket every user.
• updateAdoptionStage() — threshold-based bucketing into NEW (0 regs), LEARNING (1), ADOPTED (2–5), EXPERT (>5).
• isNewUser(), isActiveUser() — 30-day window logic anchored to System.currentTimeMillis(), with null-date guards.
• Custom equals(Object) / hashCode() based on the (userId, username, firstRegistrationDate) triple — used by collections/dedup in Fido2UserMetricsService.
• Two constructors with non-trivial initialization: the no-arg constructor zeroes counters, sets isActive=true, and stamps lastUpdated; the 2-arg constructor additionally assigns a random UUID to id.

None of this is tested today. This is the first issue in the rollout that exercises real computation rather than getter/setter wiring, and the per-method consequences of a silent regression are large (corrupted stored aggregates, mis-bucketed engagement reports, NaN leakage through the JSON API).

This is step 5 of the FIDO2 metrics test rollout (step 1 added Fido2MetricTypeTest; step 2 added Fido2MetricsConstantsTest; step 3 added Fido2MetricsDataTest; step 4 added UserMetricsUpdateRequestTest).

Describe the solution you'd like
Add a new JUnit 5 test class:

• File: jans-fido2/model/src/test/java/io/jans/fido2/model/metric/Fido2UserMetricsTest.java

The test should cover:

• Default constructor initial state: all six counters (totalRegistrations, totalAuthentications, successfulRegistrations, successfulAuthentications, failedRegistrations, failedAuthentications, fallbackEvents) are 0; isActive is true; lastUpdated is non-null and within ±1s of System.currentTimeMillis() at construction.
• 2-arg constructor: new Fido2UserMetrics("u-1", "alice") sets userId/username correctly, generates a non-null id parseable as a UUID, and inherits the default-constructor initialization (counters zeroed, isActive=true).
• incrementRegistrations(true): totalRegistrations goes 0→1, successfulRegistrations goes 0→1, failedRegistrations stays at 0, lastActivityDate and lastUpdated are both non-null and ~now.
• incrementRegistrations(false): mirrors the above but increments failedRegistrations, not successfulRegistrations.
• incrementAuthentications(true/false): symmetric to the registration tests, on the authentication counters.
• incrementFallbackEvents(): fallbackEvents 0→1, plus timestamp side effects.
• getRegistrationSuccessRate() happy path: with totalRegistrations=10, successfulRegistrations=7, returns 0.7 (delta 1e-9).
• getRegistrationSuccessRate() zero-and-null guards: returns 0.0 (not NaN) when totalRegistrations is null, and also when it is 0.
• getAuthenticationSuccessRate() happy path + guards: parallel to the registration cases.
• getOverallSuccessRate() cross-counter math: with totalRegistrations=4, successfulRegistrations=2, totalAuthentications=6, successfulAuthentications=3, returns 5/10 = 0.5. With both totals null/zero, returns 0.0. With one side null, treats it as 0 and computes from the other side.
• getFallbackRate(): happy path with mixed counters; 0.0 when both totals are zero/null; null fallbackEvents is treated as 0 (not NPE).
• updateEngagementLevel() boundary check at 50: totals 49 → MEDIUM, totals 50 → HIGH. Catches > vs >= regressions on the high threshold.
• updateEngagementLevel() boundary check at 10: totals 9 → LOW, totals 10 → MEDIUM.
• updateEngagementLevel() null totals: returns LOW (the null-safe branch must treat null as 0).
• updateAdoptionStage() boundaries: 0 regs → NEW, 1 → LEARNING, 5 → ADOPTED, 6 → EXPERT; null → NEW.
• isNewUser(): true when firstRegistrationDate is 29 days ago, false when 31 days ago, false when null. Use a fixed Date(System.currentTimeMillis() - Nd) rather than wallclock comparisons inside the assertion.
• isActiveUser(): mirrors isNewUser() against lastActivityDate.
• equals() / hashCode() contract: two instances with identical (userId, username, firstRegistrationDate) are equal and share a hash; differing in any of the three breaks equality; differing in unrelated fields (e.g. counters, engagementLevel) preserves equality (the equality is identity-tuple-only by design). Includes reflexive (x.equals(x)) and null/wrong-type (x.equals(null), x.equals("string")) cases.

Conventions to follow (same as Fido2MetricTypeTest, Fido2MetricsConstantsTest, Fido2MetricsDataTest, UserMetricsUpdateRequestTest):

• JUnit 5 (org.junit.jupiter.api).
• No Mockito needed — pure entity behavior.
• No additional dependencies — junit-jupiter-api and junit-jupiter-engine test-scope deps are already declared in jans-fido2/model/pom.xml; jans-orm-model (for the Entry superclass) is already on the model module's compile classpath.
• Group related cases into one @Test per behavior (e.g., testGetOverallSuccessRateHappyPath, testGetOverallSuccessRateZeroAndNullGuards, testUpdateEngagementLevelBoundary50, testEqualsContractForIdentityTuple).
• For timestamp side-effect assertions, use a small wall-clock window (e.g., capture before = System.currentTimeMillis() before the call, after = System.currentTimeMillis() after, assert lastUpdated.getTime() falls in [before, after]). Avoid Thread.sleep.

Acceptance criteria:

• New test file exists at the path above.
• All behaviors listed are covered.
• mvn -pl model -am test from jans-fido2/ passes locally.
• Test class runs in well under 1 second (no Thread.sleep, no I/O).
• No changes to production code under src/main.
• No pom changes required.

Describe alternatives you've considered

• Splitting this into smaller sub-issues (one per method group: counters, rates, levels/stages, equals): rejected — all the logic lives in one class with overlapping setup (the counters drive the rates which drive the levels), and splitting would either duplicate the setup or force artificial test-file fragmentation. The class file is one cohesive unit and should be covered as one.
• Skipping boundary tests and only covering happy paths: rejected — the entire risk profile here is off-by-one in the threshold ladders and NaN from unguarded division. Happy paths catch neither.
• Using a clock-injection abstraction to make isNewUser() / isActiveUser() deterministic: rejected as out of scope — the method takes its time from System.currentTimeMillis() directly and refactoring that signature is a separate change. The proposed approach (fixed Date offsets relative to current time) is robust enough for a unit test.
• Asserting on exact lastUpdated == new Date() equality: rejected — flaky; uses the small-window assertion described above instead.

Additional context
Roadmap position: step 5 of the FIDO2 metrics test rollout — and the first step that exercises computed behavior rather than value mapping. Next planned step is to strengthen the existing MetricServiceTest (jans-fido2/server/src/test/java/io/jans/fido2/service/shared/MetricServiceTest.java), replacing its assertDoesNotThrow smoke checks with real verify() / ArgumentCaptor assertions. After that, the rollout moves into the server-side service classes (Fido2MetricsService will be split across several issues — store, query, aggregate, analytics).

Same Maven module (jans-fido2/model) as issues #1–#4; with the surefire/JUnit alignment fix already in place, no further pom workarounds are required.

Suggested label: kind-test.

[coderabbitai]

🔗 Related PRs

#12405 - feat(jans-fido2): added the metrics aggregations and analytics [merged]
#12800 - feat(jans-fido2): added the final fixes and calls to the metrics-func… [merged]
#13448 - feat(jans-config-api): FIDO2 metrics endpoints [merged]
#13519 - feat(jans-auth-server): Support OAuth Client ID Metadata Document (CMID) #13220 [merged]
#13941 - test(jans-auth-server): fixing crypto client tests to have required nestedJws in JWE [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!