Налаштування тестового середовища для проєкту

Давайте чесно, писали ви коли-небудь код, який працював у вас на локальній машині, але раптом "все зламалося" на продакшені? Якщо так, то у нас погані новини: розробники про це дізнаються одразу. Ось чому тестове середовище є життєво необхідним: воно допомагає нам створювати та запускати тести поза впливом основного застосунку. Ми налаштовуємо тестову базу даних, окремі конфігурації та організовуємо тести так, щоб "болото багів" вас не затягнуло.

Підготовка тестової бази даних

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

Автоматичне створення тестової бази даних

Коли ви запускаєте тести в Django (наприклад, командою pytest), система автоматично створює тестову базу даних. Це зазвичай виглядає так:

• Django бере налаштування бази даних із settings.py.
• Створює тимчасову базу даних, ім'я якої починається з test_....
• Усі міграції автоматично застосовуються до нової бази.

Приклад із settings.py:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / "db.sqlite3",
    }
}

Якщо у вас використовується PostgreSQL або MySQL, Django створить відповідну тестову базу для кожного тестового запуску. Вам нічого не потрібно налаштовувати додатково, окрім прав на створення бази даних для користувача бази.

Як переконатися, що все працює? Спробуйте виконати будь-яку команду тестування, наприклад:

pytest

Під час запуску Django автоматично виведе щось на кшталт:

Creating test database for alias 'default'...

Якщо ви бачите це повідомлення, то тестова база успішно створена!

Організація тестів у проєкті

Уявіть собі бібліотеку, де книги валяються де завгодно. Тепер замініть "книги" на "ваші тести". Щоб не опинитися в хаосі, тести потрібно правильно організувати.

Де розміщувати тести?

Django рекомендує кілька підходів:

1. Тести в окремих файлах для кожного додатка
   Наприклад, якщо у вас є додаток blog, тести можна розмістити в такому файлі:

      blog/
          tests.py
   

2. Тести в окремих папках
   Для великих проєктів більш зручна структура з каталогом для тестів. Наприклад:

   blog/
       tests/
           test_models.py
           test_views.py
           test_urls.py
   

Для початку оберіть другий підхід: створення папки tests у кожному додатку. Це дозволить зручно групувати тести за типом.

Поради щодо організації

• Назви файлів завжди починайте з префікса test_. Це потрібно, щоб pytest їх знайшов. Наприклад: test_api.py, test_forms.py.
• Намагайтеся називати файли і тести так, щоб одразу було зрозуміло, що вони перевіряють.

Налаштування тестової конфігурації

Щоб ваші тести "жили своїм життям", можна налаштувати окремий файл конфігурації, наприклад test_settings.py.

Приклад test_settings.py

from my_project.settings import *  # Імпортуємо базові налаштування

# Використовуємо SQLite для тестів (швидко і без зайвих залежностей)
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': ':memory:',  # Використовуємо базу в пам'яті
    }
}

# Вимикаємо непотрібні middleware для прискорення тестів
MIDDLEWARE = [mw for mw in MIDDLEWARE if mw not in [
    'your_project.middleware.SomeHeavyMiddleware',
]]

# Вивід налагодження у тестах
DEBUG = False

# Налаштування e-mail
EMAIL_BACKEND = 'django.core.mail.backends.locmem.EmailBackend'

# Будь-які додаткові налаштування для тестування

Щоб тести використовували цей файл налаштувань, запустіть pytest зі змінною середовища:

DJANGO_SETTINGS_MODULE=test_settings pytest

Або налаштуйте це прямо в pytest.ini:

[pytest]
DJANGO_SETTINGS_MODULE = test_settings

Приклад базової структури тестів

Тепер, коли у нас все налаштовано, давайте створимо найпростішу структуру тестів у каталозі вашого застосунку.

Крок 1: створіть папку tests

У каталозі вашого застосунку створіть папку tests/, а всередині файл __init__.py (щоб Python знав, що це модуль).

Структура виглядатиме так:

blog/
    tests/
        __init__.py
        test_models.py
        test_views.py

Крок 2: приклад простого тесту

У test_views.py напишемо найпростіший тест:

from django.test import TestCase
from django.urls import reverse

class BlogViewTests(TestCase):
    def test_homepage_status_code(self):
        response = self.client.get(reverse('home'))  # Перевіряємо головну сторінку
        self.assertEqual(response.status_code, 200)

Цей тест перевіряє, що головна сторінка вашого блогу повертає статус 200 (OK).

Поширені проблеми та їх вирішення

Коли ти запускаєш тести вперше, можуть виникнути наступні проблеми:

1. Bugs у міграціях або моделі бази даних: Якщо міграції не проходять або модель некоректна, тести неможливо запустити. Переконайся, що твоя міграція проходить локально:

   python manage.py makemigrations
   python manage.py migrate
   

2. Змінні середовища для тестової бази даних: Якщо використовуєш PostgreSQL або MySQL, переконайся, що права на створення тестової бази є у поточного користувача.

3. Помилки залежностей додатків: Перевір, що всі додатки у INSTALLED_APPS додані коректно.

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