Где хранить ключи api используемые для тестирования открытого по?

Question

[Антон Шаманов]

Есть публичный composer пакет для отправки sms через стороннее api. Для unit тестов нужно где-то хранить ключ api чтобы конечные пользователи пакета могли подставить свой ключ и выполнить тесты. Сейчас это делается через env переменную задаваемую через конфиг phpunit. Собственно вопрос как/где лучше организовать передачу и хранение ключа?

Comments

[Денис Юрьев]

а чем dotenv не устраивает то?

[Антон Шаманов]

Денис Юрьев, просто рассматриваю другие варианты

Answer 1

[Алексей Уколов]

Что-то у вас намешано.
Юнит-тестам не нужен никакой ключ (подойдёт любая строка). Конечным пользователям не нужно тестировать пакет, разумнее его мокать.

Но если хочется всё-таки проверить, например, корректность инициализации, то решение о том, как создавать инстанс класса библиотеки, за конечным пользователем. То есть, пользователь передаёт в конструктор какую-то строку. Где он эту строку возьмёт - зависит от конкретного приложения. Современный стандарт - заполнять контейнер конфига из ENV, а потом этот контейнер использовать. Следовательно, зашивать строку в phpunit.xml - вполне нормальное решение. Если на конкретном проекте это почему-то не работает, то нужно обсуждать предметно.

Comments

[Антон Шаманов]

Конечным пользователям не нужно тестировать пакет, разумнее его мокать.

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

зашивать строку в phpunit.xml - вполне нормальное решение

не безопасно (

[Алексей Уколов]

Тогда это не юнит-тест.

Ты удивишься как часто всплывают ошибки при прогоне тестов сторонних пакетов

Да как-то за 15 лет работы ни разу у меня не возникло желания в автоматических тестах смски рассылать ¯\_(ツ)_/¯
И подобные ошибки в библиотеках - разовые акции.
Если библиотека нормальная, то там можно даже замокать HTTP-слой и вызывать всё же код самой библиотеки не затрагивая внешку.
А если библиотека не нормальная (например, она не работает на вышедшем почти 5 лет назад и уже даже не поддерживаемом PHP 8.0), то зачем вообще её использовать?

не безопасно

Конечно, ведь мы говорили о тестовой строке, а не о ключе API. Если очень хочется всё-таки пинать настоящее API, то надо смотреть, как на конкретном проекте подгружать для тестового окружения свой ENV. В Laravel, например, для этого есть специальный файл, а в Битриксе есть очень удобное нихрена.

[Антон Шаманов]

автоматических тестах смски рассылать

так он и не рассылает - у большинства сервисов есть тестовый режим

А если библиотека не нормальная

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

[Алексей Уколов]

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

[Vitsliputsli]

Антон Шаманов,

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

Речь не о том, что не нужно проверять. Речь о том, что тестирование делится на стадии. Юнит-тестирование не подразумевает взаимодействие со внешними системами, любые такие взаимодействия мокаются, это не позволит протестировать полную функциональность, но зато позволит быстро проверить огромное кол-во вариантов для конкретного юнита, что невозможно при функциональном или интеграционном тестировании. А уже интеграцию проверяют на собранном стенде, который эмулирует продовый контур, и здесь в условиях приближенных к реальным можно проверить полную функциональность. А так как это отдельный стенд, то и ключи будут лежать где-то в нем (так же как и на проде, т.е. в конфиге проекта, а не phpunit.xml). Даже если нет отдельного сервера для стенда, должна быть какая-нибудь виртуалка-стенд по-аналогии.

Answer 2

[Vamp]

Стандартной практикой является коммит в репозиторий файла phpunit.xml.dist в который прописываются все настройки по умолчанию, кроме чувствительных к безопасности (api ключи, пароли и пр). Файл phpunit.xml добавляется в .gitignore. Таким образом, если пользователю нужно кастомизировать какие-то параметры, он просто копирует файл phpunit.xml.dist в phpunit.xml и добавляет свои секреты в последний. Это безопасно, так как phpunit.xml заигнорен.

То что вы описываете - это уже не unit, а интеграционное тестирование. Скрипты для интеграционного тестирования обычно делают в отдельном testsuite и скипаются по умолчанию. Для запуска юнит тестов не должна требоваться какая-либо подготовка - только "склонировал репозиторий, запустил". Для интеграционных подготовка уже нужна. Например, юзер должен будет модифицировать phpunit.xml (не .dist!), вписав туда свой тестовый api ключ.

Соответственно, для юнит тестов достаточно в тестируемый код передать мокнутого http клиента, который будет возвращать ответ, который вернуло бы реальное стороннее api (в guzzle это делается с помощью MockHandler). Поэтому если надо просто запустить юнит тест, то ничего делать не нужно - phpunit автоматически подхватит phpunit.xml.dist, если не найдет phpunit.xml. Если надо запустить интеграционные, то юзер должен будет скопировать phpunit.xml.dist в phpunit.xml и добавить туда api ключ.

Comments

[Антон Шаманов]

спасибо, у меня в общем то так и реализовано. я скорее пытался найти какие-то альтернативы чисто из интереса "а все также делают?"