Если по тем или иным причинам вы вынуждены использовать в юнит-тестах некие секретные данные, которые не хотите светить в репозитории в конфиг-файле — как лучше поступить?
Можно, конечно, локально держать другой конфиг-файл. Но вдруг забудете и запушите свою версию?
Как то желательно иначе, чтобы не было возможности случайно слить данные в паблик (особенно если репо — открытый).
Здравствуйте, Shmj, Вы писали:
S> некие секретные данные, которые не хотите светить
а вот с этого места по подробнее, пожалуйста.
что за данные, почему не хотите светить?
все это очень подозрительно!
var secret = Environment.GetEnvironmentVariable("мой маленький секретик");
Как это ни банально, для тестов лучше тестовые данные.
Когда последний раз с этим сталкивался — делал клиента, который обращаяется к rest API, к которому надо ходить с авторизацией пользователя, разработчики API сделали ещё и метод заведения тестового пользователя, развернули тестовый стенд, где этот метод был открыт (на бою, естественно, этого метода нет).
Соответственно, при прогоне юнит-теста, инициализатор сначала обращался к этому методу и заводил пользователя, сохранял его токен локально, после чего при повторных прогонах просто загружал его из локального файла. И дальше тесты уже обращались к API с этим токеном.
Это позволило автоматизировать тестирование (на тимсити), когда агент делает обычные git clone и build, после чего спокойно крутит тесты.
Секрет должен храниться в файла. Программа должна уметь его читать. Путь к файлу с секретом должен настраиваться из конфига (например из переменных окружения) и иметь "удобное" значение по-умолчанию.
Здравствуйте, Shmj, Вы писали:
S>Если по тем или иным причинам вы вынуждены использовать в юнит-тестах некие секретные данные, которые не хотите светить в репозитории в конфиг-файле — как лучше поступить?
S>Можно, конечно, локально держать другой конфиг-файл. Но вдруг забудете и запушите свою версию?
S>Как то желательно иначе, чтобы не было возможности случайно слить данные в паблик (особенно если репо — открытый).
S>Как лучше?
1) "Секрет" должен быть environment-specific. Поэтому, программа должна уметь его обнаруживать и валидирвоать на конкретном деплое
2) Должен быть механизм "секрет-провайдера". Тогда, тестовые прогоны могут учитывать как обычные сценарии, так и negative testing (когда секрет левый и мы проверяем что те кому надо получают отлуп)
В такой формулировке — лучше всего выкинуть этот тест нафиг.
Тест, и тем более юнит (хотя тут видимо речь об интеграционном) — является полезным тестом до тех пор, пока его могут исполнить все участники процесса.
Участники процесса — это ВСЕ разработчики, и CI/CD система. Если для тебя приемлимо, что бы все участники процесса, настроили специфичные настройки у себя локально (дали доступ к чему-то / ввели свои личные креденшылы (чего они делать категорически не должны ни под каким предлогом, и первое о чём надо позаботиться — это избежать таких локальных настроек, по возможности), тогда — окей.
В противном случае: делаются тестовые логины/пароли которые статически известны.
В противном случае — такой тест можно смело удалять, потому что в 99.9% случаев его никто не будет иметь шанса запустить. Более того, если такой тест выполняется только CI/CD — то его так же можно удалять, потому, что тест который не проходит на удалённой машине к которой никто не имеет доступа, и не может быть отлажен — вызывает больше проблем, чем отсутствие такого теста вообще.
Здравствуйте, Mystic Artifact, Вы писали:
MA> Участники процесса — это ВСЕ разработчики, и CI/CD система. Если для тебя приемлимо, что бы все участники процесса, настроили специфичные настройки у себя локально (дали доступ к чему-то / ввели свои личные креденшылы (чего они делать категорически не должны ни под каким предлогом, и первое о чём надо позаботиться — это избежать таких локальных настроек, по возможности), тогда — окей.
Здравствуйте, Shmj, Вы писали:
S>Ок. Только как лучше настроить у себя локально?
Воистину, это дело вкуса. Моё предпочтение — это directory scoped файлы конфигурации, а не переменные окружения. Просто для меня актуально иметь сразу несколько конфигураций (читай чекаутов), которые настроены по разному. Хотя в итоге софт может уметь и так и так.
Ну и всё таки, если это секрет, да еще, если разработчик должен положить именно свой пароль (условно корпоративный), то хорошо бы всё таки что бы он был хотя бы зашифрован.
Здравствуйте, Shmj, Вы писали:
S>Если по тем или иным причинам вы вынуждены использовать в юнит-тестах некие секретные данные, которые не хотите светить в репозитории в конфиг-файле — как лучше поступить?
Но то это и юнит-тест, чтобы секреты ему были не нужны. Сто лет назад придумали моки. Замокай сервис занимющийся авторизацией или работой с секретами и надобность в секрете отпадет. Я вот буквально вчера писал тест для сервиса который разные важные данные может раздавать. Так там все замокано. По сути сервис работает один в окружении моков. Какие там на фиг секреты? Получил данные от моков, моки же вызвал, чтобы понять, что сервис работает как надо.
Если это интеграционные тесты, то можно сделать фэфковую инфраструктуру секреты от которой будут бесполезны всем кто за "периметром". Ну, или опять же мок смастерить, который будет эмулировать работу с секретами.
Если это данные, их можно обфусцировать (поменять по некоторому алгоритму или псевдо-случайно).
Короче, не надо реальных секретов в тестах держать. У нас за такое может прилететь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
