Как исключить тест из запуска?

Как исключить тест из запуска в автоматизации

Исключение теста из запуска — это стандартная задача в автоматизации тестирования, которая возникает по разным причинам: тест временно нестабилен (flaky), требует доработки, проверяет функционал в разработке или просто не актуален для конкретного запуска. Существует несколько подходов, которые различаются в зависимости от используемого фреймворка, инструментов и стратегии управления тестами.

Основные методы исключения тестов

1. Аннотации (Annotations) / Декораторы

В большинстве современных фреймворков для этого используются специальные аннотации (Java/JUnit/TestNG) или декораторы (Python/pytest).

В JUnit 4/5 (Java):

import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;

public class ExampleTest {
    @Test
    @Disabled("Тест временно отключен из-за бага в API")
    public void disabledTest() {
        // Код теста
    }
}

В TestNG (Java):

import org.testng.annotations.Test;

public class ExampleTest {
    @Test(enabled = false)
    public void disabledTest() {
        // Тест будет пропущен
    }
}

В pytest (Python):

import pytest

@pytest.mark.skip(reason="Функционал в разработке")
def test_example():
    assert True

2. Пользовательские метки (Tags) и категории

Позволяют более гибко управлять группами тестов, включая или исключая их по тегам.

В pytest с маркировкой:

import pytest

@pytest.mark.slow
def test_long_operation():
    # Долгий тест
    pass

# Запуск только тестов БЕЗ марки 'slow':
# pytest -m "not slow"

В TestNG через группы:

<!-- testng.xml -->
<test name="Regression">
    <groups>
        <run>
            <exclude name="broken"/>
        </run>
    </groups>
    <classes>
        <class name="com.example.TestClass"/>
    </classes>
</test>

3. Условное пропускание тестов

Иногда тест нужно пропускать при определенных условиях (версия ОС, наличие сервиса, флаг в конфиге).

Пример в JUnit 5:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.condition.DisabledIfEnvironmentVariable;

public class ConditionalTest {
    @Test
    @DisabledIfEnvironmentVariable(named = "ENV", matches = "prod")
    public void testOnlyForNonProd() {
        // Тест не запустится, если переменная ENV=prod
    }
}

Условный skip в pytest:

import pytest
import sys

@pytest.mark.skipif(sys.version_info < (3, 8), reason="Требуется Python 3.8+")
def test_new_feature():
    pass

Практические рекомендации и лучшие практики

• Всегда указывайте причину отключения. Это критически важно для поддержки кода. В аннотациях используйте параметр reason или комментарий.
• Используйте Issue Tracker ID. Связывайте отключенный тест с задачей в Jira/другой системе:

@Test
@Disabled("PROJ-123: Временное отключение из-за изменений в API")

• Регулярно ревьюьте отключенные тесты. Введите процесс регулярного аудита (@Disabled тестов), чтобы они не забывались. Некоторые тесты должны быть удалены, а не бесконечно отключены.
• Разделяйте временные и постоянные исключения. Для временных проблем используйте аннотации, для постоянных — возможно, удаление теста или вынесение в отдельный набор.
• Используйте конфигурационные файлы для гибкости. Например, в TestNG можно управлять запуском через XML, а в pytest через pytest.ini или аргументы командной строки.
• Интеграция с CI/CD. В CI можно задавать переменные окружения для динамического исключения тестов:

# Пример для pytest
pytest -m "not (slow or api)" --tb=short

• Альтернатива: вынос в отдельный модуль. Иногда логично просто вынести нестабильные или долгие тесты в отдельный модуль/пакет и не включать их в стандартный прогон.

Чего следует избегать

• Комментирование кода теста — худшая практика, так как тест просто исчезает из поля зрения.
• Исключение через if в коде теста без корректной обработки (просто return) — это усложняет поддержку и логирование.
• Массовое отключение тестов без анализа причин — приводит к «проседанию» покрытия и накоплению технического долга.

Выбор конкретного способа зависит от контекста: для быстрого временного исключения подойдут аннотации, для управления наборами в CI — теги и конфигурационные файлы. Главное — поддерживать процесс в управляемом состоянии, чтобы исключенные тесты не становились «мертвым» кодом.