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

Как лучше организовать передачу и хранение API ключа для юнит-тестов в публичном composer пакете, чтобы конечные пользователи могли подставлять свой ключ? В настоящее время используется переменная окружения, заданная через конфигурацию PHPUnit.
  • 23 апреля 2025 г. 7:15
Ответы на вопрос 2
Хранение и управление API-ключами — важный аспект разработки, особенно когда дело касается открытого программного обеспечения. Вот несколько рекомендаций, как лучше организовать передачу и хранение API-ключа для юнит-тестов в публичном Composer пакете:

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

2. **Конфигурационные файлы**: Позвольте пользователям вашего пакета создавать конфигурационные файлы (например, `config.php`), где они могут задать свой API-ключ. Вы можете предложить файл с примером конфигурации (например, `config.example.php`), чтобы пользователи знали, какую структуру использовать.

3. **Использование dotenv**: Рассмотрите возможность использования библиотеки, такой как `vlucas/phpdotenv`, которая позволяет пользователям загружать переменные окружения из `.env` файла. Это будет удобным способом управления конфигурацией для многих пользователей.

4. **Документация**: Обязательно добавьте документацию, которая объясняет, как пользователи могут настроить свои API-ключи, используя предложенные вами методы. Укажите, какие переменные нужно установить, или как настроить конфигурации.

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

6. **На уровне тестов**: Для юнит-тестов вы можете использовать шаблоны или заглушки, чтобы имитировать работу API. Это помогает избежать необходимости использования реального ключа в тестах, которые могут быть выполнены автоматизированно на CI/CD инструментах.

Пример кода для использования переменной окружения и библиотеки `dotenv`:

```php
// Используйте vlucas/phpdotenv
require 'vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

$apiKey = getenv('API_KEY');

if (!$apiKey) {
    throw new \Exception('API_KEY is not set. Please set it in your .env file.');
}

// Используйте $apiKey в вашем коде
```

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

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