1Тести й безпечне оновлення

Твій бот уже вміє багато: вітається, показує підказку, слухається лише власника, запускає скрипти, пише першим за розкладом. Кожна нова вправа ризикує зламати щось зі старого. Досі ти перевіряв усе очима: писав боту (або запускав try_bot.py) і дивився на відповідь. Чим більше команд, тим довше так перевіряти — і тим легше щось пропустити.

Сьогодні цю роботу візьме програма. У теці ~/app/tests з’являться автотести: короткі функції, які самі «пишуть» боту повідомлення й звіряють відповіді з очікуваними. Дванадцять тестів перевіряють /start, /help, /whoami, відмову чужому, створення й запуск скрипта, зупинку скрипта, що завис, і те, що розклад не спрацьовує двічі за день. Одна команда — і за секунду видно: або все гаразд, або що саме зламалося.

Друга половина заняття — безпечне оновлення. Скрипт deploy.sh перед розгортанням нової версії проганяє тести й відмовляється працювати, якщо хоч один червоний. А якщо тести зелені, але нова версія не запустилася, скрипт сам повертає код до останньої справної версії. Наприкінці GitHub почне сам проганяти ті самі тести після кожного git push і ставити біля коміту зелену галочку.

До кінця заняття в тебе буде:

• файл tests/test_bot.py: щонайменше 12 тестів, зелені, плюс один твій власний;
• два досліди «навмисно зламати»: підказку /help і замок власника — обидва разом дають червоний тест;
• скрипт deploy.sh: двічі поспіль дає однаковий результат, відмовляє при червоному тесті, відкочує при мовчазній службі (обидва випадки ти перевіриш у копії, не ризикуючи справжнім ботом);
• файл .github/workflows/tests.yml і зелена галочка на сторінці репозиторію.

Telegram на цьому занятті не потрібен: тести розмовляють із функцією handle_update напряму, так само, як try_bot.py. Усе зробить і той, хто ще не має акаунта в Telegram.

Тарас на занятті 09 вирішив зробити код гарнішим і переписав у bot.py рядок із перевіркою власника. Перевірив: написав боту від свого імені /run privit — працює. Зберіг комітом. Тиждень потому виявилося, що тепер /run виконує будь-хто: у новому рядку Тарас випадково переплутав порівняння. Власника він перевіряв, чужого — ні, бо чужого в нього під рукою не було.

Така помилка має назву — регресія (від слова «регрес», рух назад): зламалося те, що раніше працювало, часто зовсім не там, де ти правив. Очима її шукати тяжко, бо перевіряєш лише щойно змінене.

Автотест — програма, яка сама виконує дію у твоєму коді й звіряє результат з очікуваним. Очікуване записують командою assert («стверджую, що це правда»):

assert 2 + 2 == 4          # правда: нічого не відбувається, програма йде далі
assert 2 + 2 == 5          # неправда: помилка AssertionError, тест «впав»
assert "/ask" in "/ask питання"   # слово in для рядків: чи є шматок усередині

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

pytest — програма-«перевіряльник» для Python (вона вже стоїть у спільному середовищі сервера). Правила прості: бере файли test_*.py з теки tests, у кожному — функції, назва яких починається з test_, і по черзі їх виконує. Ось справжній тест із сьогоднішнього файлу:

def test_start_greets_by_name():
    assert "Оля" in bot.handle_update(message("/start"))

Функція message("/start") збирає таке саме повідомлення, яке Telegram надіслав би боту, від користувачки Олі. bot.handle_update(...) — та сама функція, що відповідає людям (заняття 02): вона отримує повідомлення й повертає текст. Тест перевіряє, що в привітанні є ім’я «Оля».

Результат pytest показує одним рядком: крапка — тест зелений (пройшов), літера F — червоний (упав). Нижче pytest пише, у якому рядку що не збіглося. Дванадцять крапок і 12 passed — усе гаразд.

Тест, який зелений завжди, нічого не стереже. Ось тест, що виглядає солідно, але марний:

def test_help():
    assert bot.handle_update(message("/help"))      # лише «відповідь не порожня»

Він пройде, навіть якщо підказка стане словом «привіт». Справжній тест порівнює з тим, що саме має бути: assert "/ask" in bot.handle_update(message("/help")).

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

Тести запускаються на тому самому сервері, де живе твій бот. Якби вони писали у справжню базу чи справжні скрипти, то кожен запуск лишав би сміття, а тест «чужий» міг би щось зіпсувати. Тому на початку файлу стоїть підготовка, до того як bot імпортується. Вона складається зі змінних оточення — налаштувань, які програма читає не з коду, а із середовища, де її запустили; bot.py читає їх на старті:

• APP_DB — окрема тимчасова база в тимчасовій теці; справжня ~/data/app.db лишається цілою;
• SCRIPTS_DIR і SCHEDULE_FILE — тимчасові теки для скриптів і розкладу;
• STATS_FILE і APP_LOG — тимчасові сторінка статистики й журнал, щоб тести не переписали справжні ~/www/stats.html і ~/logs/app.log;
• OWNER_CHAT_ID=7 — у тестах власник завжди чат номер 7, а «чужий» — 8; твій справжній номер ніде не потрібен;
• BOT_POLLING=0 — бот не з’єднується з Telegram;
• LLM_BASE_URL «нікуди» — ШІ недоступний, і тест перевіряє, що бот не падає, а чемно відповідає.

Ще одна хитрість — підміна (в pytest її роблять через monkeypatch): на час одного тесту підставляємо інше значення. Скрипт, що завис, зупиняється через 10 секунд — чекати стільки в кожному запуску довго, тож у тесті ліміт тимчасово стає 1 секунда. А замість справжнього надсилання в Telegram bot.tg підміняється функцією, яка лише складає повідомлення в список — і тест бачить, що саме бот «надіслав», нічого нікуди не відправляючи.

Побічна вигода: тести швидкі й повторювані. Запусти їх хоч сто разів, хоч уночі — результат той самий.

Розгортання (по-англійськи deploy) — це момент, коли нова версія коду починає працювати замість старої. У нашому випадку: код лежить у ~/app, а перезапуск служби club-bot змушує її прочитати нові файли. До перезапуску служба працює зі старим кодом у пам’яті, навіть якщо файли вже змінено.

Скрипт deploy.sh робить кроки в такому порядку, і порядок важливий:

Тег (англ. tag) — це постійне ім’я для конкретного коміту, як закладка в книзі. last-good означає «остання версія, яка запустилась і відповідала». Відкат — це git reset --hard last-good: гілка main і файли в теці стають такими, як у цій закладці. Саме це слово означає «відкат» у нашому курсі; про повернення до випущеної версії 1.0 буде на занятті 13. Зламану версію скрипт не губить: ставить на неї тег broken, і потім можна глянути, що було не так: git diff last-good broken.

Чому при червоних тестах відкату немає, а при мовчазній службі є? У першому випадку служба ще не перезапускалась і далі працює зі старим кодом — відкочувати нічого. У другому — вже запущено новий код, який не завівся, і його треба прибрати. А ще скрипт вимагає, щоб усе було збережено комітом: reset --hard стирає незбережені зміни, а правила безпеки такі — не стирати те, чого немає в історії.

Змінні оточення DEPLOY_RESTART, DEPLOY_CHECK, DEPLOY_WAIT дозволяють підмінити «як перезапустити», «як перевірити» і «скільки чекати» ззовні, не змінюючи файлу. Так ми перевірятимемо червоний тест і відкат на копії, не торкаючись справжньої служби.

Тести на твоєму сервері проходять — і це приємно, але це ще не все. На сервері в тебе лежать файли, яких немає в Git: .env, база, може, забутий scripts.py, що не потрапив у коміт. «У мене працює» — улюблене виправдання програмістів, і причина часто саме в цьому.

CI (безперервна перевірка, англ. continuous integration) вирішує це так: після кожного git push окремий комп’ютер береться з нуля, завантажує лише те, що є в репозиторії, і проганяє тести. На GitHub це робить GitHub Actions. Що саме робити, записано у файлі .github/workflows/tests.yml. Це YAML — формат, де структуру задають відступами (два пробіли на рівень):

• on: [push, pull_request] — запускати на кожен push і на кожен pull request (запит «підтягни мої зміни», який роблять, коли хочуть додати свій код у чужий репозиторій);
• jobs → test → runs-on: ubuntu-latest — завдання (job) іде на чистій віртуальній машині з Linux (це «комп’ютер», який існує лише на час перевірки);
• steps — кроки: забрати код (actions/checkout), поставити Python, поставити пакети pyyaml (читає YAML-файли, його потребує код бота) і pytest, запустити python -m pytest -q.

Біля коміту на сторінці репозиторію з’являється: жовте коло — іде перевірка, зелена галочка — усе пройшло, червоний хрестик — щось упало (можна клацнути й побачити журнал, як у термінала). Хрестик — не ганьба, а сигнал: хтось, зазвичай ти сам, щось забув зберегти комітом.

Секрети (.env, токен бота) на GitHub не потрапляють узагалі — вони в .gitignore. Тому тести й не вимагають справжнього токена: це ще одна причина, чому вони працюють із тимчасовими значеннями.

Кожне питання оцінюється відразу в браузері — це лишається так само. Ця кнопка лише надсилає підсумок учителю, щоб відповіді не зникли разом із закритою вкладкою.

Список критеріїв і що саме вони означають — у таблиці вище, «Що перевіряє автоматика». Тут — та сама перевірка, але прямо зараз, без очікування на найближчий прохід за розкладом.

1. Ще три тести. Напиши й додай у tests/test_bot.py: (а) /every 25:00 privit від власника відповідає помилкою з «ГГ:ХХ»; (б) після /new x1 echo 1, /every 09:00 x1 команда /stop x1 відповідає «прибрано», а /schedule знову показує «порожній»; (в) /new Великі echo 1 відмовляє із «латиницею». Кожен тест перевір на живучість: тимчасово зламай відповідний рядок у scripts.py і переконайся, що тест червоніє, потім поверни. Має бути не менше 16 зелених.
2. Побач червоний хрестик і прибери його. Додай у tests/ файл test_zlamanyi.py з assert 1 == 2, збережи комітом і зроби git push github main. Подивись у вкладці Actions хрестик і журнал. Прибери файл (git rm tests/test_zlamanyi.py), збережи комітом, відправ — і дочекайся галочки. Увага: не запускай ./deploy.sh, поки цей файл лежить у репозиторії. Наприкінці в тебе має бути зелена галочка: її бачить викладач.
3. Поясни своїми словами (напиши 3–4 речення в README.md під заголовком «## Тести й оновлення»): що робить deploy.sh при червоних тестах і що — коли служба не відповіла; чому в першому випадку відкату немає.
4. Підготуйся до заняття 13. На ньому ти показуватимеш бота гостям і випускатимеш версію 1.0. Подумай, які 4–5 команд покажеш за три хвилини і що зробиш, якщо Telegram або ШІ раптом не відповідатимуть.
5. Збережи. git add -A, git commit -m "Заняття 12: домашня робота", git push origin main і git push github main.

32pytest: command not found, No module named pytest або No module named 'yaml'

Ти запустив системний Python, а потрібні пакети стоять у спільному середовищі. Завжди пиши повну команду: /opt/club/venv/bin/python3 -m pytest -q. Щоб не набирати щоразу, у тій самій теці можна запускати ./deploy.sh: він уже використовує потрібний Python.

33L12.1: ERROR collecting tests/test_bot.py або червоний тест, хоча бот працює

• ModuleNotFoundError: No module named 'scripts' (чи init_db, db, env) — тест імпортує те, що має лежати в ~/app: ls ~/app. Нема scripts.py — скопіюй із /opt/club/kurs/09/; нема init_db.py чи db.py — із /opt/club/kurs/04/;
• червоний test_start_greets_by_name, test_help_lists_commands — ти змінив тексти бота на попередніх заняттях. Прочитай рядок після E: чекали одне, отримали інше. Тест — це договір: або поверни старе слово в боті, або зміни очікування в тесті, але свідомо;
• test_every_message_is_counted: IndexError — у тимчасовій базі немає таблиці users. Дивись, чи є init_db.main() на початку тестів і чи не стерто remember(sender) у handle_update;
• пів хвилини очікування — спрацьовує справжній виклик ШІ: перевір, що на початку тестів лишилася змінна LLM_BASE_URL з адресою «нікуди».

34L12.2: «я зламав бота, а тести лишилися зеленими» (і ще два повідомлення)

Перевірка пише одне з трьох. «Я зламав бота, а тести лишилися зеленими» — назвала, що саме зламала. Знайди тест на це місце й подивись, що він порівнює. «У чистій копії тести червоні» — тести червоні вже зараз, ще до поломки: запусти pytest у ~/app і виправ (і переконайся, що все збережено комітом). «Не знайшов рядків, які я зазвичай ламаю» — ти сильно переписав bot.py чи scripts.py; порівняй з /opt/club/kurs/09/. Типова причина першого випадку: assert reply (відповідь «не порожня») замість assert "лише для власника" in reply. Додавай порівняння з конкретним текстом або наслідком (файл не створився, повідомлення пішло одне, а не два). Якщо ти видалив один із готових тестів — поверни його з /opt/club/kurs/12/tests/.

35L12.3: ./deploy.sh — Permission denied, є незбережені зміни, служба не відповіла

• Permission denied або command not found — немає виконуваного права: chmod +x ~/app/deploy.sh, потім збережи комітом (git add deploy.sh && git commit);
• bad interpreter — перший рядок має бути точно #!/usr/bin/env bash; найкраще скопіювати оригінал заново з /opt/club/kurs/12/;
• є незбережені зміни — це не помилка скрипта, а запобіжник: git status --short, git add -A, git commit -m "…";
• бот не ожив за 30 с — подивись tail -n 30 ~/logs/club-bot.log і systemctl --user status club-bot. Якщо тег last-good вже був, скрипт сам відкотився, а git diff last-good broken покаже, що було не так;
• перший запуск кілька секунд «думає» на кроці git pull: скрипт звертається до репозиторію на сервері. Зачекай хвилину; якщо виведе fatal — це не зупинить скрипт, але перевір, куди веде git remote -v, і що гілка в тебе справді main;

36L12.4 або L12.5: «у репозиторії немає deploy.sh», «не користується змінною DEPLOY_RESTART», «відкату немає»

Перевірка працює з копією того, що збережено комітом: що лежить лише на диску, вона не бачить. Виконай git status --short (маєш побачити порожньо) і git ls-files | grep -E "deploy.sh|tests" (обидва мають бути в списку). Якщо ти переписував скрипт сам — порівняй з оригіналом: diff ~/app/deploy.sh /opt/club/kurs/12/deploy.sh. Скрипт має: (1) зупинятися з exit 1 після червоного pytest до перезапуску; (2) після вдалої перевірки ставити git tag -f last-good; (3) у разі мовчазної служби робити git reset --hard last-good, перезапускати й виходити з кодом 1; (4) брати «як перезапустити» й «як перевірити» зі змінних DEPLOY_RESTART і DEPLOY_CHECK.

37L12.6: workflow не зараховано або не запускається на GitHub

• файл має лежати рівно в ~/app/.github/workflows/tests.yml (з крапкою на початку першої теки);
• «не збережено комітом» — файл не потрапить у репозиторій, якщо ти забув git add -A перед git commit: виконай обидві команди, потім git push github main;
• у файлі стоїть клавіша Tab замість пробілів — відкрий у nano і виправ відступи (два пробіли на рівень);
• вкладка Actions порожня — запуск з’являється лише після git push github main з цим файлом; перевір репозиторій: той, куди веде git remote -v для github.

38L12.7: бот не живий після розгортання

systemctl --user status club-bot і tail -n 30 ~/logs/club-bot.log. Якщо щойно був ./deploy.sh і він відкотився, то код уже той, що працював; подивись git log --oneline -3 та git tag. Служба не стоїть після перезапуску — запусти її: systemctl --user start club-bot, зачекай 5 секунд і повтори cat ~/data/bot_state.json: last_poll має бути свіжим (не старшим за дві хвилини); немає токена в .env — бот не питатиме Telegram і last_poll не з’явиться.

39На GitHub червоний хрестик, а на сервері тести зелені

Відкрий запуск у вкладці Actions, клацни на червоний крок і прочитай рядок після E чи ModuleNotFoundError. Найчастіше це файл, що є на сервері, але не в Git: git status --short покаже його знаком ??. Додай git add, збережи комітом і відправ. Другий варіант — тест залежить від чогось зі свого сервера (наприклад, від справжнього .env): тести мають використовувати лише тимчасові значення з початку файлу.