Home

Автор: Маарет Пюхяярви (Maaret Pyhäjärvi)

Оригинал статьи

Перевод: Ольга Алифанова

13 шаблонов для тестирования API

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

1. Фокус: работа с ограниченным пониманием

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

Многие тестировщики начинают с поля ввода. Это как "заполнение пустот" или тестирование поиска Google. Какие позитивные данные я могу сюда ввести?

А где вообще найти API для исследования? Поспрашивать коллег, взять то, что люди называют API или библиотекой в этом проекте? Использовать инструменты вроде Fiddler, которые отслеживают технологии, к которым обращается API приложения?

Кто-то другой начнет с документации и сбора заявлений о продукте.

Еще можно определить репрезентативный сценарий использования, чтобы получить базовые представления, как это будет выглядеть, когда заработает.

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

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

2. Поиск структурных элементов

Покрутите ваш продукт, и вы увидите эти элементы. Это вызовы и операции, ввод и вывод, запросы и ответы. Это исключения и зависимости, и все это существует с определенной целью. Поймите, какие рукоятки в вашем API можно повернуть во время тестирования.

Вы можете поиграть с элементами, и не понимая их предназначения. Их предназначение откроется вам в процессе изучения. Однако элементы – это те пустоты, которые вам нужно заполнить: что именно вы вызываете, с какими значениями, и что ожидаете получить. Смоделируйте этот процесс.

Вы можете назвать ваш ввод запросами, а вывод – ответами. Определитесь со своим словарем.

Посмотрите вокруг для расширения своей модели – нельзя ли построить что-то поверх этих блоков?

3. Окружение, от которого зависит API

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

Разберитесь, что входит в ваш фронт работ ("ваш API"), а что вне его ("экосистема, в которой ваш API приносит пользу"). Нарисуйте схему и расширяйте ее по мере того, как вы узнаете что-то новое.

4. Определенный пользователь с определенными задачами

API кем-то используется – это и конечные пользователи, и разработчики, а разработчики – это люди со специфичными привычками и ожиданиями.

Они ожидают, что все будет идиоматично соответствовать их привычному языку и следовать конвенциям, к которым они привыкли. Они ожидают определенного стиля документации и внятности.

Лучшие API – это те, где время на обработку "Hello world" (т. е. примера, на котором можно посмотреть рабоспособность) невелико, а пример не заставляет выходить за рамки IDE.

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

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

5. Удобство использования API

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

Что будет, если неверное использование API нарушит не только время прогона и скорость обратной связи, но и время компиляции?

Что, если методы следуют консервативной стратегии перегрузки – когда два метода с одинаковым именем никогда не имеют одинакового количества аргументов, и пользователи могут спутать ввод? Я никогда не слышала об этой концепции, пока не начала исследовать API, и стала гуглить, что говорят люди об удобстве использования API.

Существует даже подход "Опыт разработчика" (DX), применяющий концепции пользовательского опыта (UX) к API, которыми пользуются разработчики. DX концентрируются на вещах вроде "Время на Hello world" (время запуска в вашем окружении) и "Время до работоспособного приложения" (использование в реальном мире). Эти идеи естественным образом рождаются в процессе исследовательского тестирования.

6. Зачем это будет использоваться?

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

Задавать вопрос о предназначении очень важно в исследовательском подходе, даже имея дело с интерфейсом кода:

• Почему это вообще существует?
• Кто находит это полезным, и почему именно?
• Что может вмешаться в ожидаемый и фактический результат?

7. Думайте о жизненном цикле

Скорее всего, вы тестируете версию, которую вам выдали – возможно, были предыдущие версии, и наверняка будут последующие: не меняется только мертвое ПО. Как это повлияет на ваше тестирование?

• Изменит ли это подход к именно этому API?
• Может ли пользователь узнать версию этого API?
• Как насчет удаления функциональности или замены вызовов API? Как долго вы будете сохранять нерекомендуемые штуки в вашем интерфейсе?
• Помешает ли это вам исправлять простейшие опечатки?

8. Гуглите понятия!

Источники информации нынче повсюду. Встретилось незнакомое слово? Гугл – ваш лучший друг! Мне как-то пришлось гуглить "Консервативную стратегию перегрузки" после того, как я прочитала, что ее наличие отличает хороший API от плохого.

Ответы на ваши вопросы, как правило, у вас прямо под рукой.

9. Сотрудничайте, подтвердите свои представления фактами

Вы не одиноки – поработайте с кем-нибудь в паре. Найдите человека, которому  можно задавать вопросы. Даже если вы начинаете тестировать самостоятельно, вы необязательно должны продолжать в том же духе. Объединитесь в пару с программистом, особенно если вы работаете над API вашей собственной компании.

Я часто рекомендую Сильную работу в паре. Если ваш напарник лучше генерирует идеи для тестирования, возьмите клавиатуру себе и общайтесь с ним, чтобы его идеи при помощи ваших рук воплотились в жизнь.

Сотрудничать можно не только в плане тестирования – вы можете сотрудничать с целью выяснить, что именно еще вам нужно протестировать. Попробуйте совместно создать ментальную карту – это отличный способ генерировать информацию, которая ляжет в основу исследовательского тестирования.

10. Документация очень важна для API

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

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

11. Исследуйте продукт, чтобы задокументировать его.

Создание документации – не самый сильный навык программистов. Исследуя API, вы, возможно, станете экспертом по этому конкретному продукту. Пусть эти знания послужат пользователям!

• Четко и внятно опишите ваш продукт для новичков, использующих его.
• Как следует объясните, что именно делает функциональность и почему.
• Почистите автоматически созданную документацию.

12. Некоторые шаблоны видны только при повторении

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

Вот пара моих любимых цитат в тему:

• "Не то чтобы я очень умный – я просто дольше копаюсь в проблемах" (Альберт Эйнштейн).
• "Чем больше я практикуюсь, тем удачливее я становлюсь" (Арнольд Палмер).

Я узнаю куда больше, когда копаю глубже, по сравнению с первоначальными результатами. Ручное повторение может стать залогом таких открытий, даже в API.

13. Одноразовая автоматизация

Когда вы создаете свои тесты, они в итоге могут быть автоматизированы. Зачастую у вас есть какой-либо уровень автоматизации, позволяющий получить доступ к API. У вас есть запросы и ответы, и, возможно, связанный с ними код. Некоторые API невозможно запустить без кода. Ваш код может и не включать автоматические проверки результатов, если вы просто запускаете API, а не проверяете отклики. Но ваш код может также включать теории, касающихся предположительно верных идей – к примеру, изучения, действительно ли будет редким "редкое" сообщение об ошибке при большом объеме данных.

Создавая автоматизацию, критически спросите себя:

• Возможно, она одноразового применения?
• Приносит ли она ценность, дает ли новую информацию прямо сейчас?
• Хотите ли вы потом поддерживать эти тесты?

Ваш набор автотестов потребует поддержки. При падении тестов вы будете в них разбираться. Выбирайте с умом. Научитесь понимать, что значит "с умом".

Заключение

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

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