Add tests for service info, user auth, task geometry pruning, and overpass task building#1247
Conversation
…d overpass task building - Service info endpoint: verify build and runtime info is returned - User whoami: cover valid apiKey, session, and rejection auth paths - Task geometry pruning: regression test for ClassCastException on Json.arr-backed arrays (#1243) - Overpass challenge building: success, wrong content-type, and 504 busy-server failure paths
UserServiceSpec "get user mappers for challenge" asserted result.head.id,
but getChallengeMappers has no ORDER BY so row order is arbitrary and
differs across Postgres instances. The test passed locally but failed in
CI (76 did not equal 59). Both callers (NotificationService,
AchievementService) iterate the full list and don't depend on order, so
assert membership instead of head ordering rather than adding a needless
ORDER BY.
Also harden getSessionByApiKey: a malformed API key without a "|"
separator threw ArrayIndexOutOfBoundsException (caught, but logged a
misleading ERROR). Parse with split("\\|", 2) and pattern match so
malformed keys return None cleanly; this also preserves raw keys that
themselves contain "|".
|
|
Fixed the inconsistent issue with a test, this is ready. |
jake-low
left a comment
jake-low
left a comment
There was a problem hiding this comment.
I reviewed the code changes and skimmed the new test code; LGTM.
start validating overpass (via a mocked request)
Just to double check: this means we aren't sending any requests to overpass-api.de when the test suite runs, right? (I don't want to generate any unnecessary load for that service by pinging it every time our CI runs)
That's exactly right, the request doesn't visit the real server. The test is safe from overpass going down for updates or changes in its response structure (say, more element nodes are in a response). The mocked response is hard-coded in the test file and what we can do is copy this style to do additional validation around any pain points with overpass. |
3 participants
Create a few test cases to get familiar with the framework and a more complex test to start validating overpass (via a mocked request).