test: add unit tests for the Elasticsearch filters - #36
Merged
Conversation
Cover the custom filters' apply() query DSL and getDescription() descriptors directly, without Elasticsearch or the kernel — the filters are constructed with inert stubs for the AbstractFilter metadata factories (never called once `properties` is set). - MatchFilter/BooleanFilter/TagFilter/IdFilter: exact term/match clauses, boost shape, comma-splitting, single-vs-list return; "0" reaches ES (guarding the strict-guard behaviour). - DateRangeFilter: fallback/explicit operators, `between` → exclusive gt/lt, and the two current error leaks (malformed `between` → \InvalidArgumentException, unknown operator → native \Error) plus the dead `throwOnInvalid` flag, pinned as current behaviour.
|
✅ No changes detected in API specification |
…ests # Conflicts: # CHANGELOG.md
…ests # Conflicts: # CHANGELOG.md
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
1 participant
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.
Add fast unit coverage for the custom Elasticsearch filters (
src/Api/Filter/ElasticSearch/*). They currently have no unit tests — only behavioural (ES-backed) coverage that asserts result counts, which can't pin the exact query DSL a filter emits.Approach
Each filter extends API Platform's
AbstractFilter, whose constructor needs three metadata factories. When a filter is configured with an explicitpropertiesmap (as every resource does),AbstractFilter::getProperties()yieldsarray_keys($properties)and never touches the factories — so the tests construct filters with inert stubs and assertapply()/getDescription()directly. No kernel, no Elasticsearch: 37 tests run in ~20ms.Coverage
match/termsclause shape, boost placement, comma-splitting, unset/empty skipping, single-vs-list return."0"is asserted to reach ES (guards the strict-guard behaviour from the earlierempty()removal).rangeDSL;between→ exclusivegt/lt(a consumer-visible semantic); everygetDescription()[operator]variant.between→ uncaught\InvalidArgumentException; unknown operator ([foo]) → native\Error— two distinct paths that leak as HTTP 500 today; and thethrowOnInvalidconfig flag is demonstrably dead.Verification
bin/phpunit tests/Unit→ 37 tests, 49 assertions, no notices (stubs, not mocks, so PHPUnit 13's no-expectations notice stays clean). php-cs-fixer clean; full suite 201 tests / 492 assertions green. Every test method carries a short context/goal comment.Tests only — no product code changed.