Привіт! Хочу лишити це тут🙏
І завтра допишу другу частинку.
—————————————
➡️Дуже популярні помилки в автоматизації - ЧАСТИНА ПЕРША
(частковий витяг з нашої дискусії з Бетельгейзе з Володимиром + мої думки)
1️⃣Коли на CI не видно червоного статусу після того, як якісь тести падають
Чому так може бути?
Команда, яка запускає тести, не повертає свій статус-код, і в результаті CI завжди показує "зелений" статус.
Приклад помилки:
pytest test_example.py | exit 1
Так робити не можна - оскільки команда завжди завершиться з кодом 1 через exit 1, незалежно від того, чи пройшли тести.
Як правильно:
Команда для запуску тестів повинна бути простою і повертати свій власний статус-код
pytest test_example.py
Це дозволить CI відобразити реальний статус тестів.
2️⃣Коли ми перевіряємо елементи списку, але не перевіряємо, чи список не порожній
Чому це важливо?
Якщо список порожній, ми можемо пропустити важливу проблему. Наприклад, якщо пошук поверне 0 елементів або викличе помилку, тест не зайде в цикл, і проблема залишиться непоміченою.
Приклад помилки:
for element in some_elements_to_validate:
assert validate_element(element) # Перевірка коректності елементів
Якщо some_elements_to_validate порожній, перевірка ніколи не виконається
Як правильно:
Спочатку перевірте, що список не порожній:
assert some_elements_to_validate, "Список порожній! Можлива проблема в пошуку."
for element in some_elements_to_validate:
assert validate_element(element), f"Елемент {element} некоректний."
3️⃣Відсутність прав на CI і байдужість до цього
Чому це проблема?
Якщо тестувальник не має прав на налаштування CI, він не може:
🔹Розуміти, як налаштовані пайплайни
🔹Вносити зміни в тестову конфігурацію
🔹Ефективно реагувати на проблеми.
Це може призвести до нестабільної автоматизації, де тестувальник залежить від DevOps або розробників.
Як діяти:
Тестувальник повинен:
🔹Наполягати на отриманні прав доступу до CI
🔹Розуміти, як працює пайплайн (від запуску до генерації звітів)
🔹Поліпшувати процес, не перекладаючи відповідальність на DevOps
DevOps відповідають за інфраструктуру (наприклад, налаштування віртуальних машин чи доступів), але тестовий пайплайн повинен бути в зоні відповідальності тестувальника.
Приклад:
Тестувальник має розуміти і мати доступ до конфігурацій пайплайнів, наприклад:
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Run tests
run: pytest test_example.py --alluredir=./allure-results
І тестувальник повинен мати змогу налаштовувати такі параметри.
І завтра допишу другу частинку.
—————————————
➡️Дуже популярні помилки в автоматизації - ЧАСТИНА ПЕРША
(частковий витяг з нашої дискусії з Бетельгейзе з Володимиром + мої думки)
1️⃣Коли на CI не видно червоного статусу після того, як якісь тести падають
Чому так може бути?
Команда, яка запускає тести, не повертає свій статус-код, і в результаті CI завжди показує "зелений" статус.
Приклад помилки:
pytest test_example.py | exit 1
Так робити не можна - оскільки команда завжди завершиться з кодом 1 через exit 1, незалежно від того, чи пройшли тести.
Як правильно:
Команда для запуску тестів повинна бути простою і повертати свій власний статус-код
pytest test_example.py
Це дозволить CI відобразити реальний статус тестів.
2️⃣Коли ми перевіряємо елементи списку, але не перевіряємо, чи список не порожній
Чому це важливо?
Якщо список порожній, ми можемо пропустити важливу проблему. Наприклад, якщо пошук поверне 0 елементів або викличе помилку, тест не зайде в цикл, і проблема залишиться непоміченою.
Приклад помилки:
for element in some_elements_to_validate:
assert validate_element(element) # Перевірка коректності елементів
Якщо some_elements_to_validate порожній, перевірка ніколи не виконається
Як правильно:
Спочатку перевірте, що список не порожній:
assert some_elements_to_validate, "Список порожній! Можлива проблема в пошуку."
for element in some_elements_to_validate:
assert validate_element(element), f"Елемент {element} некоректний."
3️⃣Відсутність прав на CI і байдужість до цього
Чому це проблема?
Якщо тестувальник не має прав на налаштування CI, він не може:
🔹Розуміти, як налаштовані пайплайни
🔹Вносити зміни в тестову конфігурацію
🔹Ефективно реагувати на проблеми.
Це може призвести до нестабільної автоматизації, де тестувальник залежить від DevOps або розробників.
Як діяти:
Тестувальник повинен:
🔹Наполягати на отриманні прав доступу до CI
🔹Розуміти, як працює пайплайн (від запуску до генерації звітів)
🔹Поліпшувати процес, не перекладаючи відповідальність на DevOps
DevOps відповідають за інфраструктуру (наприклад, налаштування віртуальних машин чи доступів), але тестовий пайплайн повинен бути в зоні відповідальності тестувальника.
Приклад:
Тестувальник має розуміти і мати доступ до конфігурацій пайплайнів, наприклад:
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Run tests
run: pytest test_example.py --alluredir=./allure-results
І тестувальник повинен мати змогу налаштовувати такі параметри.