Home

Автор: Дейв Вестервельд (DaveWesterveld)
Оригинал статьи
Перевод: Ольга Алифанова

API - отличная штука. Это мощный способ заставить разные приложения работать вместе. API позволяют легко интегрировать приложения, и на них основана львиная доля современного Интернета. Они прекрасны.

Но.

API может меняться. Если это внутренний API, то особой проблемы нет, хотя в некоторых компаниях API-команда может быть полностью отделена от тех, кто пользуется API, и поэтому даже изменения внутреннего API могут вызывать проблемы. В больших компаниях с отдельными командами разработки API принято относиться к внутреннему API так же, как к постороннему. API-разработчики также зачастую версионируют API, чтобы вы могли пользоваться устаревшими версиями, ничего не переделывая на своей стороне, но что будет, когда компания решит отказаться от старых версий или перестанет их поддерживать?

Изменения ПО неизбежны. Любая нужная людям и активно используемая часть ПО может измениться. Но нам, людям, почему-то очень сложно это осознать. Мы хотим иметь возможность “сделать и забыть”, но зная, что ПО будет меняться, мы не можем этого сделать. Если в двух словах, тут можно применить две стратегии:

Сначала тестируйте

Первая стратегия - полностью принять тот факт, что ПО будет меняться, и нельзя просто начать пользоваться API, надеясь на лучшее. Вместо этого мы создаем набор тестов API, убеждающихся, что он ведет себя так, как должен. Затем мы прогоняем эти тесты перед каждым билдом и используем их для проверки, что API все еще работает как надо, до того, как он будет задействован в нашем ПО.

Этот подход, очевидно, потребует усилий, так как вам нужно заранее создать тесты, а затем прогонять и поддерживать их, но временами это может оказаться хорошей стратегией. Если вы используете сторонние API для ключевой функциональности своего приложения, стоит проверить API до того, как вы начинаете им пользоваться. Чем критичнее информация, которую вы получаете через API и чем ужаснее результат его отказа, тем осторожнее надо быть и тем раньше проверять его.

Отслеживайте

Есть и другой подход - вместо тестирования API до его использования, отслеживайте проблемы и исправляйте их постфактум.

Эта идея не всегда нравится тестировщикам, так как мы хотим предотвратить проблемы до того, как они увидят мир, но в некоторых ситуациях такая стратегия имеет смысл. Возможно, используемый API не дает никакой критичной информации, и если он перестанет работать, это не сильно затронет ваших клиентов. Или, возможно, вызовы API предназначены для внутренних скриптов, которые помогают вам в работе, но сломайся они на несколько дней - ничего страшного не произойдет. Во множестве ситуаций сломанная функциональность не создает особых проблем, если все можно вовремя исправить. В таких случаях уместнее просто отслеживать проблемы и разбираться с изменениями после того, как обнаружено, что что-то сломалось.

Напомню также, что мониторинг необязательно должен быть чем-то большим, сложным и высокотехнологичным. К примеру, у меня есть курс по тестированию API, где я даю множество примеров API, чтобы студенты на них практиковались. ПО, однако, меняется, и иногда используемые примеры не работают из-за изменений в API. Это произошло в ходе курса, и студент спросил меня, почему пример не работает. Я разобрался в ситуации и обновил курс, чтобы пример стал рабочим. Сообщение от студента - это пример мониторинга. Не очень-то эффективного, так как он зависит от доброй воли (или степени раздражения) студента, но использование API так или иначе отслеживается.

Мониторинг не должен быть высокотехнологичным, но вам надо обдумать, как вы узнаете о том, что что-то пошло не так. Надо ли ждать, пока на это пожалуется клиент (см. мой пример), или у вас есть внутренний пользователь или процесс, которые сообщат, что что-то сломалось? Можно даже рассмотреть специализированное ПО, если для вас важно узнавать об опасных изменениях вовремя.

Снижение эффекта

Неважно, какой подход вы выберете - вам нужен способ снизить эффект от проблем в ситуации, когда API не делает то, что вы от него хотите. Мониторинг, сообщающий о неудачных вызовах API, не несет особой пользы, если вы не знаете, как это починить, или как обойти проблему, пока она не будет починена. То же самое применимо и к раннему тестированию. Если у вас нет четкого плана, как внедрить нужные изменения, если API перестанет работать - вы можете оказаться в ситуации, когда вы не вносите необходимые изменения из-за “сломанного API”. Знание, что вы будете делать, когда (если) API сломается - важная часть работы со сторонними API.

Это также важно по другой причине. Неважно, сколько вы тратите на тестирование и мониторинг — иногда все может упасть очень странным образом. Есть вещи, с которыми тестирование просто не может справиться. Что, если сервис, предоставляющий ваш API, упадет или перестанет работать (или компания обанкротится, или откажет вам в доступе)? Что вы будете делать? Думаю, один из вариантов - отрицать: этого никогда не произойдет! Но если COVID-19 чему-то нас научил, так это никогда не говорить ничего подобного! Неплохо иметь стратегию на случай такого фиаско - как минимум, информировать пользователей, что что-то пошло не так, а в идеале - предоставлять им какую-либо (возможно, урезанную) функциональность.

Заключение

Тестирование сторонних API на самом деле очень похоже на любое другое тестирование ПО. Вам нужно внимательно обдумать, какое тестирование имеет смысл в контексте, в котором вы находитесь.

Что касается сломанных API-вызовов в моем курсе - я применил очень низкотехнологичный (и неэффективный) способ мониторинга - ждал, что студенты сообщат мне о проблемах. Не то чтобы мне это нравилось. Кто знает, сколько народу просто пропускает сломанное, пока кто-то наконец-то не задаст вопрос и не даст мне знать, что происходит. Я бы хотел раньше узнавать о том, что один из моих вызовов ломается или переезжает в другое место. Планирую написать простенький скрипт, который будет раз в день пинговать мои API и отправлять емейл, если конечная точка исчезает или меняется. Хочется сделать мониторинг эффективнее. Что насчет вас? Есть ли участки в приложении, где мониторинг заключается в ожидании, что кто-то что-то заметит? Может, это можно улучшить простым скриптом?

Обсудить в форуме