FIX: Assert at least one matched User-Agent, not exactly one#332
Merged
Conversation
Jamesr51d
approved these changes
Jul 23, 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
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.
Relates to #TASK
Updates the on-premise device detection test for the unified detection result
shape introduced in 51Degrees/device-detection-cxx#362 (merged in
51Degrees/device-detection-cxx#385).
test_matched_user_agentsasserted that a single User-Agent produces exactlyone matched User-Agent. #362 removed the fast path that coupled result shape to
evidence cardinality, so detection now produces one result - and so one matched
User-Agent - per component the engine populates. A single User-Agent yields
several rather than one.
Change
assertEqual(len(...), 1)becomesassertGreaterEqual(len(...), 1). The exactnumber depends on which components the data file makes available, so pinning a
literal would be brittle across data file revisions.
The new assertion holds under both the old shape (1) and the new one, so this
can land ahead of the submodule bump rather than having to ship with it.
Sequencing
The pending submodule PR #331 bumps
cxxfrom9027aa8toc7b2822, which iswhere the new shape arrives. Merging this first means #331 goes green on its
own; merging #331 first would turn the nightly red until this lands.
Verification
Test-only change; syntax checked with
python -m py_compile. Not executedlocally - the on-premise package needs a compiled SWIG extension that was not
built in the environment used. CI is the check.
Related
The same assertion is being corrected in device-detection-java,
device-detection-dotnet, device-detection-node and device-detection-go.
device-detection-php is unaffected - it asserts no result counts.