Можно ли писать тесты без фреймворков?

Можно ли писать тесты без фреймворков?

Да, безусловно можно. Написание тестов без специализированных фреймворков — это абсолютно выполнимая задача, и такой подход имеет как исторические корни (раньше фреймворков просто не было), так и практическое применение в определённых сценариях. Однако, прежде чем решиться на это, необходимо глубоко понимать цели, плюсы, минусы и альтернативные издержки такого решения.

Как это выглядит на практике?

По своей сути, автоматизированный тест — это скрипт или программа, которая выполняет ряд действий (например, взаимодействует с вашим приложением) и проверяет, соответствуют ли фактические результаты ожидаемым. Всё это можно реализовать на "голом" языке программирования. Рассмотрим упрощённый пример проверки функции сложения на Python без использования pytest, unittest или nose.

# test_math_manual.py - Самописная "тестовая система"

def add(a, b):
    # Тестируемая функция (обычно находится в другом модуле)
    return a + b

def run_test(test_name, condition):
    """Примитивная функция-раннер для проверки условия."""
    if condition:
        print(f"[PASS] {test_name}")
    else:
        print(f"[FAIL] {test_name}")

# Сами тестовые случаи
def test_add_positive_numbers():
    result = add(2, 3)
    expected = 5
    run_test("test_add_positive_numbers", result == expected)

def test_add_negative_numbers():
    result = add(-2, -3)
    expected = -5
    run_test("test_add_negative_numbers", result == expected)

def test_add_zero():
    result = add(0, 5)
    expected = 5
    run_test("test_add_zero", result == expected)

# "Запускатор" тестов
if __name__ == "__main__":
    test_add_positive_numbers()
    test_add_negative_numbers()
    test_add_zero()

Это рабочая, хотя и примитивная, тестовая система. Она выполняет проверки и выводит результаты. В принципе, её можно развивать: добавить фиксации (setup/teardown), сбор статистики, вывод в файл, управление зависимостями.

Преимущества написания тестов без фреймворков

• Полный контроль и гибкость. Вы создаёте архитектуру, идеально заточенную под специфические нужды проекта. Нет ни одной лишней детали.
• Отсутствие внешних зависимостей. Не нужно изучать документацию фреймворка, следить за его обновлениями или разрешать конфликты версий.
• Максимальная прозрачность. Вы точно знаете, как работает каждый механизм вашей тестовой системы, так как написали его сами.
• Полезный учебный опыт. Понимание того, как устроены фикстуры, ассерты, репортеры и раннеры "под капотом", делает вас значительно более сильным инженером.

Критические недостатки и риски

• Колоссальные затраты времени и ресурсов (Reinventing the Wheel). Вам придётся с нуля разрабатывать и отлаживать функциональность, которая давно решена и оптимизирована в готовых фреймворках:

    *   **Богатый набор ассертов** (проверки на равенство, исключения, срезы, время выполнения и т.д.).
    *   **Фикстуры и хуки** (setup/teardown на уровне модуля, класса, функции).
    *   **Параметризация тестов** (запуск одного теста с разными наборами данных).
    *   **Управление параллельным запуском.**
    *   **Продвинутые репортеры** (HTML, XML, интеграция с CI/CD и системами отслеживания задач).
    *   **Плагины и расширяемость.**

• Сложность поддержки и низкая сопровождаемость. С ростом кодовой базы тестов ваша самописная система превратится в "второй проект", который нужно документировать и поддерживать. Новым членам команды придётся изучать не только фреймворк приложения, но и вашу уникальную тестовую инфраструктуру.
• Высокий риск ошибок. Баги могут быть не только в тестируемом приложении, но и в логике вашей тестовой системы, что приведёт к ложноположительным или ложноотрицательным результатам.
• Проблемы с интеграцией. Готовые фреймворки имеют встроенную поддержку популярных инструментов (Allure, Jenkins, TeamCity, Selenium Grid). Интеграция самописной системы потребует дополнительной разработки.

Когда это может быть оправдано?

1. Образовательные цели. Чтобы понять фундаментальные принципы построения тестовых систем.
2. Экстремально специфичные окружения. Например, тестирование встроенного ПО (embedded systems) с жёсткими ограничениями по памяти, где нельзя добавить сторонние библиотеки.
3. Микросервис или скрипт из 100 строк. Когда overhead от подключения большого фреймворка несоизмерим с пользой.
4. Создание собственного специализированного фреймворка. Команды в крупных компаниях (Google, Meta, Netflix) часто создают внутренние инструменты, но это делают эксперты, и эти инструменты потом обслуживают сотни разработчиков.

Вывод

Писать тесты без фреймворков можно, но в подавляющем большинстве коммерческих проектов — крайне нецелесообразно. Использование зрелых фреймворков (таких как pytest, JUnit, TestNG, Jest и др.) — это не дань моде, а следование принципам инженерной эффективности. Они позволяют сосредоточить усилия на главном — написании качественных тестовых сценариев и поиске дефектов в продукте, а не на изобретении и поддержке собственной инфраструктуры. Решение отказаться от фреймворка должно быть исключительно осознанным, взвешенным и обоснованным конкретными, вескими техническими ограничениями.