How Do You Test a Map’s Coordinate Ordering?
From the earlier reference collection. Read the current software blog.
Use a reference point with distinguishable latitude and longitude values and assert each documented output field.
Pick an asymmetric example
Coordinate-order bugs often survive tests that use values with similar magnitudes or zeros. Choose a known location whose latitude and longitude are clearly different, and keep the expected pair in the fixture with named fields. For example, a point near a northern mid-latitude coast might have latitude around 47 and longitude around -122; the exact reference coordinate should come from the application's chosen test fixture.
Assert latitude and longitude separately. A test that checks only that two numbers were emitted cannot detect an accidental swap. If a library uses an array, verify the documented order at that boundary and the mapping into named application fields.
Test the full path to the map
A parser may correctly read named lat and lon fields, while a map adapter expects a coordinate pair in a different convention. Exercise the conversion layer that joins these representations. Confirm that the marker receives the expected latitude and longitude in the expected slots.
Use an injected map adapter or a lightweight mock that records the coordinate argument. This avoids depending on pixel placement or a live tile service for a basic ordering test. A separate integration test can verify that a marker appears at the intended region if visual rendering is important.
Add boundary and sign checks
Include a southern or western coordinate when practical. Negative signs carry geographic meaning, and a dropped sign can move a point across an equator or prime meridian. Also check valid ranges: latitude lies between -90 and 90, while longitude lies between -180 and 180. A swapped pair may sometimes remain in range, so range validation supplements rather than replaces the known-point assertion.
If the application accepts GeoJSON or another external representation, keep one fixture in that format and test its documented coordinate sequence explicitly. Do not infer ordering from a generic array without consulting the format contract used by the code.
Make the assertion readable
Use named expected values, include a comment describing the reference location, and make a failure print the received pair. Avoid fragile equality checks on transformed floating-point values if conversion or rounding occurs; compare within the precision the application retains.
A focused coordinate test catches a visually expensive mistake with a few deterministic values. It also gives future contributors a clear reminder that ordering is part of the interface contract, not an incidental detail.