Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Складіть однаковий список config keys для local, dev і CI без environment prefixes у коді.
Опишіть, хто створює test user, як він резервується для parallel worker і як відновлюється після failure.
Позначте зовнішні auth dependencies та окремо визначте production acceptance check і test-only seam.
Config matrix і state diagram без shared mutable user між parallel workers.
Описує config scopes та способи побачити origin активного setting.
Гітігнор та як працювати з гітом та не помилитись → Першоджерело ↗В окремому навчальному repository додайте правила для .venv/, .env і test results.
Перевірте кожен path через git check-ignore -v.
Задайте local user.name і user.email, потім перевірте їх через git config --list --show-origin.
Команди перевірки та staged diff, у якому немає .env і generated artifacts.
Рівень, з якого Git читає setting: system, global, local, worktree або command. --show-origin і --show-scope допомагають знайти джерело ефективного значення.
Приклад відсікає coercion id із str у int, відсутній required field і невідомі extra fields.
Valid payload приймається; два invalid payloads спричиняють ValidationError.
Міграція бази даних і тестування даних →Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати `user.name` і `user.email` локально. Практичні команди: `git config --list --show-origin` показує активні значення та їх джерела; `git config user.name` і `git config user.email` читають поточну ефективну ідентичність; `git config --local user.name "Name"` та `git config --local user.email "email@example.com"` задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.
Наступний рівень — JSON, YAML, XML або інший структурований формат, який можна десеріалізувати у типізований config object. Це допомагає групувати налаштування за сервісами й середовищами, але файл із секретами все одно не можна публікувати в Git. У складнішій системі конфігурацію може віддавати централізований config server. Він дозволяє сервісам отримувати актуальні домени, ключі й feature flags, інколи без повного redeploy. Тестовий код не повинен створювати паралельне джерело правди, якщо може безпечно використати той самий контрольований механізм, що й продукт.
В build configuration задаються specification URL/file, output directory, generator/language, package names і config options. Окрема task спочатку отримує spec, потім генерує sources. Вихід кладеться в `build/`, а не редагується вручну. Так generator залишається build product, а не другим source of truth.
Для dev, staging, UAT та інших середовищ можуть існувати окремі локальні файли, і кожен із них має бути проігнорований. Якщо файл випадково додали до індексу, простого нового правила в `.gitignore` недостатньо: треба забрати його зі staged/tracked стану й тільки тоді перевірити ignore. Середовище не завжди визначається окремим доменом. Маршрутизація може залежати від path, cookie, custom header або feature flag; у production подібний механізм використовується для canary release. У тестах ці параметри мають бути явною конфігурацією, а не розкиданими константами. Ланцюжок розвитку у відео: hardcode → `.env` → структурований config → централізований config server. Перехід потрібен лише тоді, коли попередній варіант уже створює вимірювану незручність або ризик.
Якщо команда не може створити користувача в потрібному статусі або змінити його стан, неможливо гарантувати комбінаторне покриття критичних flows. Це треба формулювати через вплив: які сценарії не перевіряються, скільки триває підготовка та який ризик проходить у release. У регульованих системах інколи дозволений лише затверджений набір акаунтів. Тоді файл із ними залишається поза Git, передається через CI secret або контрольований config service, а тест обирає вільний профіль відповідного типу. Випадковий вибір без reservation не вирішує concurrency: потрібна оренда, блокування або розподіл акаунтів між workers.
Код має звертатися до стабільних логічних ключів на кшталт `BASE_URL`, не до `DEV_BASE_URL` або `STAGE_BASE_URL` з ручним replace. Цільове середовище вибирає джерело значень, а не інші назви змінних. Завдяки цьому локальний і CI-запуск проходять тим самим шляхом. У CI значення зберігаються як захищені secrets/variables або як секретний файл. Репозиторій містить лише `.env.example` чи аналогічний шаблон зі структурою та без реальних credentials. Якщо використовується config server, CI може зберігати лише мінімальні credentials для доступу до нього.
Найгірший варіант — один статичний користувач у локальному config. Він блокує паралельність і звужує набір доступних станів. Трохи кращий, але все ще дорогий процес — просити іншу команду вручну створювати набір акаунтів після кожного refresh тестового середовища. Якщо tester не може сам створити invoice, user або іншу передумову, перевірка залежить від чужого робочого часу. Це не просто незручність автоматизації, а властивість системи: feedback loop довгий, а критичні сценарії важко повторювати. Обмеження потрібно фіксувати як testability risk і обговорювати з командою продукту.
Початкова структура може бути простою: спільний config, `web` із pages/components, `api` із clients/controllers та DTO, а за потреби — робота з database. Не треба заздалегідь будувати повну enterprise-ієрархію. Коли database-код розростається, його можна винести на окремий рівень і розділити на entities та repositories/DAO. Це наступна ітерація після появи кількох tables і повторюваних CRUD operations, а не стартова вимога для першого test suite.
Demo показує real failures: missing generated client, incompatible Spring types, Jackson/Gson annotations, date/time mappings і auxiliary dependencies. Проблема не завжди у spec — generator version, selected library і dependency graph мають суміщатися. Потрібно pin generator version, зберігати config у repository і перевіряти clean generation в CI. Якщо generated code вимагає постійних manual edits, generator не виконує свою роль.