Інтеграційні тести в проектах OSS - як поводитися з сторонніми сторонами з аутентифікацією?

Один з моїх ( з відкритим вихідним кодом) хобі проектів є резервним інструментом , який робить автономні резервні копії репозиторіїв з GitHub, Bitbucket і т.д.
Він називає Інтерфейс API хостерів , щоб отримати список сховищ, а потім він використовує Git / Mercurial / все , щоб клонувати / перетягніть сховища на локальний комп'ютер.

Тому у мене є інтеграційні тести, де я викликаю API GitHub, з аутентифікацією.
(і коли функція клонування / витягування закінчена, ймовірно, будуть тести, які клонують сховища з GitHub, і їх також потрібно автентифікувати)

Я створив користувача та організацію, спеціально для використання в цих тестах на інтеграцію.

Проблема: Я не можу просто зашифрувати паролі десь у вихідному коді, оскільки це відкритий код, а код є відкритим на GitHub.

Що я зараз роблю

У тестах я отримую всі імена користувачів, паролі та імена сховищ від змінних середовища.
Ось приклад :

config.Name = TestHelper.EnvVar("GithubApiTests_Name");
config.Password = TestHelper.EnvVar("GithubApiTests_PW");

( TestHelper.EnvVarце допоміжний метод, який отримує значення змінної середовища і видає виняток, коли його не існує)

Потім у мене є пакетний файл, який встановлює ці змінні середовища.
Справжній ( environment-variables.bat) викликається в моєму сценарії збірки і перед виконанням тестів, але ігнорується в контролі джерела, тому він фактично не знаходиться в моєму сховищі.

Що знаходиться в системі управління версіями є environment-variables.bat.sample, який встановлює ті ж змінні оточення, але з фальшивими паролями:

rem copy/rename this file to environment-variables.bat

echo Setting environment variables for integration tests...

set GithubApiTests_Name=scm-backup-testuser
set GithubApiTests_OrgName=scm-backup-testorg
set GithubApiTests_PW=not-the-real-password
set GithubApiTests_Repo=scm-backup

Тож я можу клонувати репозиторій на своїй машині, перейменувати цей файл environment-variables.bat, замінити підроблений пароль справжнім, і всі інтеграційні тести спрацюють.

Це працює і з постійною інтеграцією - я використовую AppVeyor, і там я можу встановити ці змінні середовища у веб-інтерфейсі .

Що мені не подобається в цьому

Я думаю, що це не вдале рішення для проекту OSS, а особливо не для цього проекту:

Теоретично, учасник мого проекту міг би зараз запускати інтеграційні тести:

створивши власного користувача тесту та тестову організацію на GitHub
створення деяких тестових сховищ
створення власної версії environment-variables.batз різними значеннями

Проблема полягає в тому, що моя програма зможе створити резервну копію декількох хостерів вихідного коду.
Зараз він підтримує лише GitHub, але додати підтримку більшої кількості хостерів буде легко, додавши кілька класів, які реалізують правильні інтерфейси.

Тож коли я впроваджую підтримку для більшої кількості хостерів пізніше, кількість змінних середовищ зростатиме.
Щоб мати змогу виконати всі інтеграційні тести, потенційний дописувач створив би своїх користувачів, організацій та тестових сховищ у GitHub, Bitbucket, GitLab, .... і хто знає, скільки ще, і додав би їх до своєї environment-variables.batверсії.

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

Я знаю, що інші проекти роблять щось подібне до того, що я зараз роблю.
Наприклад , Octokit.net має сценарій для налаштування змінних оточуючих середовищ для інтеграційних тестів, що викликають API GitHub.
Але їм потрібен лише один користувач і одна організація, а мені знадобиться набагато більше.

Можливо, мені не потрібно рішення, яке дає змогу учаснику фактично виконувати всі інтеграційні тести.
Наприклад, якщо хтось захоче зробити свій внесок у підтримку GitHub мого проекту, йому потрібно буде лише запускати тести інтеграції GitHub.
Тож, можливо, мені просто потрібен здоровий спосіб, щоб я міг розділити свої інтеграційні тести на нескінченну кількість "груп" (?), А потім сказати "і тепер виконати всі тести, що належать до групи" Github "".

— Крістіан Шпехт
джерело

Я думаю, що ваша поточна установка просто чудова, але я б вніс кілька коректив.

Щоб мати змогу виконати всі інтеграційні тести, потенційний дописувач створив би своїх користувачів, організацій та тестових сховищ у GitHub, Bitbucket, GitLab, .... і хто знає скільки ще, і додав би їх до своїх змінних середовища .bat версія.

Так, це правда, але учасники не обов'язково повинні запускати всі тести на інтеграцію, перш ніж створювати PR для свого проекту. Після створення PR, CI запустить повний набір тестів.

Звичайним є тестовий набір, який якось неможливо легко запустити. Для багатьох організацій вони підтримують тестові набори, на які потрібні кілька днів, тому розробники повинні вибірково запускати тести, які легко виконувати, і просувати код вперед для більш жорсткого тестування. Я пропоную той же підхід.

Для постійних / довірених дописувачів ви можете зробити їх фактичними учасниками у вашому проекті, що повинно дозволити їм запускати ІП у своїй галузі, перш ніж робити PR.

При цьому, ви не заважаєте учасникам тестування виконувати весь набір тестів. Вони можуть надати власні облікові дані GitHub або створити власні тестові акаунти, і постійні учасники, ймовірно, це роблять.

Я пропоную коригування:

По-перше, зробіть більшість тестів блоку тестового покриття. Вони повинні охоплювати всі гілки вашої кодової бази.

По-друге, пишіть інтеграційні тести, де висміюється кінцева точка. Ви навіть можете знущатися над транспортним шаром цих API та імітувати потоки запитів / відповідей HTTP, запустивши підроблену послугу відпочинку GitHub. Наприклад (у псевдокоді):

// Test failed authentication to GitHub
val server = new WebServer("localhost", 9453, { request =>
    return Response(401, "unauthenticated")
})
server.start()
val backupService = new GitHubBackupService("http://localhost:9453")
backupService.backup must throw UnauthenticatedException()
server.stop()

Ці тести будуть складнішими, але дозволять вам це зробити

Тестуйте без створення підроблених облікових записів та сховищ
Тестові умови відмови, які важко було б імітувати за допомогою справжнього GitHub. Наприклад, 502 відповіді, час очікування з'єднання, незвичайні / нерозбірливі органи відповідей.

По-третє, відключіть будь-які тести, які потребують спеціальних знань, працювати під нормальною збіркою. У більшості інструментів управління побудовою є спосіб розділити тести інтеграції або тестувати теги та вибірково запустити їх. Співробітники повинні мати можливість створювати та тестувати програмне забезпечення без попередньої конфігурації. Повний набір тестів повинен запускатися після кожної збірки в CI.

Нарешті, задокументуйте тести та як їх запустити у вашій тестовій документації, щоб учасники могли вибрати їх запускати.

— Самуїл
джерело