Геопространственное ПО легко разработать и протестировать целиком на удобных, аккуратных примерах: чистый адрес в крупном городе, домашний широкополосный IP-адрес, точка, находящаяся далеко от любой границы или границы часового пояса. Каждый из этих тестов будет стабильно проходить, и каждый из них почти ничего не скажет вам о том, как система поведёт себя в ситуациях, которые с наибольшей вероятностью вызовут проблему, когда она встретится с реальными, более беспорядочными данными в продакшене.
По-настоящему полезный набор тестов для геопространственного ПО должен намеренно включать более сложные случаи, которые вся эта серия статей разбирала по отдельности: адрес в стране без привычной нумерации домов, запрос для точки в непосредственной близости от государственной границы, отметку времени, попадающую точно в момент перехода на летнее или зимнее время, IP-адрес, заведомо принадлежащий пулу CGNAT мобильного оператора или спутниковому интернет-провайдеру, координату возле полюсов, где допущения, основанные на долготе, начинают ломаться, и почтовый индекс из страны со сравнительно грубыми почтовыми данными, а не из страны с необычайно подробными справочными данными.
Ни один из этих сценариев не является экзотическим или маловероятным, придуманным исключительно ради полноты. Каждый из них представляет реальную, регулярно встречающуюся категорию входных данных, которую любая достаточно большая и действительно глобальная аудитория рано или поздно и вполне предсказуемо вам отправит, часто раньше, чем вы ожидаете. Система, которую никогда не проверяли на таких данных, не сломается громко и очевидно, так, чтобы проблему было легко диагностировать. Чаще всего она откажет тихо, вернув правдоподобный, но незаметно неверный результат, который проходит все поверхностные проверки и проявляется как реальная проблема гораздо позже, обычно в виде запутанного обращения в поддержку или необъяснимой бизнес-метрики, которая не сходится, а к этому моменту отследить её истинную первопричину уже значительно сложнее.
Создание такого набора тестов требует той же дисциплины, что описана ранее для измерения точности и покрытия: фиксированный, намеренно разнообразный, многократно используемый набор тестовых входных данных, который проверяется не только на то, возвращается ли вообще правдоподобный ответ, но и именно на то, ведут ли себя поля precision и confidence в этом ответе разумно и последовательно с учётом реальной сложности конкретного входа. Результат с низкой уверенностью и грубой точностью для действительно трудного случая является правильным, честным итогом, и его следует считать пройденным тестом. Уверенно неверный результат или необработанная ошибка и есть тот настоящий сбой, который стоит поймать раньше, чем его найдут за вас ваши пользователи.
Наша документация описывает точные поля и поведение каждого эндпоинта, и это правильная отправная точка для создания такого намеренно «враждебного» набора тестов для тех пограничных случаев, которые важнее всего именно для вашего приложения и его пользователей.