Repository navigation
MLE-33562: Re-enable the 8 dead methods in GeospatialRegionQueriesTest - #1989
hmadala001 wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
🔵 Needs a closer look
The revised precision boundary and re-enabled float queries require live MarkLogic validation because the double-only test index’s cross-precision behavior cannot be confirmed from Java sources.
No open issues 🎉
What changed in this PR
Restores eight inactive geospatial query tests in the core Java client library, bringing region-query and coordinate-precision checks back into the JUnit test suite.
Changes:
- Replaces
@Disabledwith@Teston all eight methods. - Adds an explicit result-count assertion to the region-query test.
- Adjusts the precision-test point to distinguish float and double behavior beyond the documented server tolerance.
| File | Description |
|---|---|
marklogic-client-api/src/test/java/com/marklogic/client/test/GeospatialRegionQueriesTest.java |
Re-enables eight tests, strengthens a result assertion, and adjusts the precision-test coordinate. |
Review effort: Balanced
This reverts commit eb7d50f. MLE-33562 Re-enable the 8 dead methods in GeospatialRegionQueriesTest Root cause: the methods were never run. They had @ignore and no @test under JUnit 4, and the JUnit 5 migration (3ff91b9) turned @ignore into @disabled without adding @test. The test-app already defines the geospatial region path indexes on /country/region (wgs84 and wgs84/double), so no index change is needed. Restored @test on all 8 methods. Seven passed as-is. testGeospatialRegionDoubleQuery failed because it queried a point 2e-8 degrees from the polygon vertex, which is inside the server's double-precision tolerance, so the wgs84/double query matched. Float precision matches any point within about 1e-6 of the vertex and double precision distinguishes anything from about 1e-7 upward, so the query point is now 10.0000003, inside that band. testGeospatialRegionQuery only asserted inside a loop over the results, so it passed with zero results; it now asserts exactly one result. MLE-33562 Temporarily pin PR build to MarkLogic 12.2.20261005 latest-12 now resolves to 12.2.20261109, where mlDeploy fails with XDMP-BAD (Bad ElemNode::elemNodeRep) in temporal:set-lsqt-automation. Pin the PR stage to the previous build by digest. Revert to :latest-12 once the server is fixed. Update ClientApiFunctionalTest.java Revert "MLE-33562 Temporarily pin PR build to MarkLogic 12.2.20261005" This reverts commit 8605947. Co-Authored-By: Copilot <223556219+Copilot@users.noreply.github.com>
cda8d8e to
264f6d5
Compare
prgs-rsingh
left a comment
prgs-rsingh
left a comment
There was a problem hiding this comment.
Verified all 8 re-enabled tests in GeospatialRegionQueriesTest and the temporary Jenkinsfile image pin:
Restored @test annotations: All 8 methods in GeospatialRegionQueriesTest (which had @disabled without @test after the JUnit 5 migration) are now actively executed, restoring coverage for geoRegionPath, geospatialRegionConstraint, CoordinateSystem.WGS84 / WGS84DOUBLE, CoordinateSystem.getOther(...), and float vs. double precision queries.
Strengthened testGeospatialRegionQuery (line 146): Adding assertEquals(1, summaries.length) before iterating over summaries prevents a false-positive pass if zero documents are returned.
Precision boundary adjustment in testGeospatialRegionDoubleQuery (line 199): Adjusting pointCoordinate from 10.00000003 (2e-8 from the 10.00000001 vertex) to 10.0000003 (2.9e-7 from the vertex) cleanly sits outside the server's double-precision tolerance while remaining indistinguishable at 32-bit float precision (ulp(10.0f) ≈ 9.54e-7).
Jenkinsfile pin (8605947): Good catch pinning pull-request-tests to MarkLogic 12.2.20261005 by digest while latest-12 (12.2.20261109) has the XDMP-BAD issue in temporal:set-lsqt-automation during mlDeploy. Merging this (and rebasing the other open PRs) will unblock their Jenkins PR builds as well.
NiteshMehta
changed the title
Enabled Test cases and tested in jenkin runs too
https://ml-clt-jenkins.progress.com/blue/organizations/jenkins/devexp%2FJava-Client%2Fjava-client-api/detail/PR-1989/2/pipeline