test: fill in unit test coverage for DataExportParams validation predicates#24469
Open
jason-p-pickering wants to merge 4 commits into
Open
test: fill in unit test coverage for DataExportParams validation predicates#24469jason-p-pickering wants to merge 4 commits into
jason-p-pickering wants to merge 4 commits into
Conversation
…icates Follow-up from DHIS2-21821 / PR #24465. Before that fix, DataExportParams had no direct unit tests for any of its validation predicates, which is likely how the lastUpdated/lastUpdatedDuration branches were silently dropped from hasPeriodFilters() during the 2.43 SQL-export rewrite (#22406) without any test catching it. Coverage existed only indirectly via slow integration tests asserting the resulting ErrorCode. Adds direct unit tests for every branch of hasDataElementFilters, hasOrgUnitFilters, isExactOrgUnitsFilter, isPeriodOverSpecified, isDateRangeOutOfBounds, isLimitOutOfBounds, isOrgUnitGroupsOverSpecified, plus the previously-untested true-branches of hasPeriodFilters itself (periods, periodTypes, startDate+endDate, includedDate). Verified isPeriodOverSpecified and isDateRangeOutOfBounds tests aren't vacuous by temporarily dropping a conjunct from each in production code, confirming the corresponding _OnlyFalse test caught it, then restoring (net diff to DataExportParams.java is zero). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Date.after() is strict (>), so a single-instant/single-day range (startDate == endDate) is currently treated as valid, not out of bounds. This boundary — the exact line between valid and invalid — wasn't covered by the earlier StartBeforeEndFalse/StartAfterEndTrue tests. Verified via mutation testing: swapped the strict startDate.after(endDate) check for an inclusive !startDate.before(endDate) in DataExportParams, confirmed only the new test failed (all 33 others stayed green), then restored (net diff to DataExportParams.java is zero). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
david-mackessy
approved these changes
Jul 17, 2026
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up from DHIS2-21821 / #24465. That PR noted:
This PR fills that gap: test-only change, no production code touched.
hasDataElementFilters,hasOrgUnitFilters,isExactOrgUnitsFilter,isPeriodOverSpecified,isDateRangeOutOfBounds,isLimitOutOfBounds,isOrgUnitGroupsOverSpecified.hasPeriodFiltersitself (periods,periodTypes,startDate+endDate,includedDate— only the false/lastUpdated-exclusion cases existed before).DataExportParamsTest.Test plan
isPeriodOverSpecified,isDateRangeOutOfBounds) aren't vacuous: temporarily dropped a conjunct from each inDataExportParams.java, confirmed the corresponding_OnlyFalsetest failed for the right reason, then restored the original code (git diffon the production file is empty)dhis-apimodule test suite passesmvn spotless:checkclean🤖 Generated with Claude Code