Какой уровень тестирования используется в контексте приложения?

Уровни тестирования в контексте приложения

Тестирование — это систематическая проверка приложения на соответствие требованиям и обнаружение дефектов. Существует пирамида тестирования, которая определяет, какой уровень тестов использовать и в каком количестве.

Пирамида тестирования

        /\     E2E тесты (10%)
       /  \    Интеграционные (20%)
      /____\   Unit тесты (70%)

1. Unit тесты (70% от всех тестов)

Unit тесты — самый низкий уровень, тестируют отдельные методы и классы в изоляции.

public class CalculatorTest {
    private Calculator calculator;

    @Before
    public void setup() {
        calculator = new Calculator();
    }

    @Test
    public void testAddition() {
        assertEquals(4, calculator.add(2, 2));
    }

    @Test
    public void testDivisionByZero() {
        assertThrows(ArithmeticException.class, 
            () -> calculator.divide(10, 0));
    }
}

Характеристики:

• Быстрые (выполняются миллисекунды)
• Изолированные (без БД, сети, файловой системы)
• Использует mocks/stubs (Mockito, PowerMock)
• Легко дебажить
• Часто запускаются (в т.ч. в CI/CD)

2. Интеграционные тесты (20% от всех тестов)

Интеграционные тесты — проверяют взаимодействие нескольких компонентов (сервис + БД, сервис + внешний API).

@RunWith(SpringRunner.class)
@SpringBootTest
public class UserServiceIntegrationTest {
    @Autowired
    private UserRepository userRepository;
    
    @Autowired
    private UserService userService;

    @Test
    public void testCreateAndFindUser() {
        User user = new User("John", "john@example.com");
        userService.saveUser(user);
        
        User found = userRepository.findByEmail("john@example.com");
        assertNotNull(found);
        assertEquals("John", found.getName());
    }
}

Характеристики:

• Медленнее чем unit тесты (секунды)
• Используют реальную БД (testcontainers, H2)
• Проверяют логику работы компонентов вместе
• Требуют подготовки окружения
• Запускаются реже (перед commit, в CI)

3. E2E тесты (10% от всех тестов)

End-to-End (E2E) — тесты полного сценария от пользователя через весь stack приложения.

// Пример с Selenium/Playwright
public class LoginE2ETest {
    private WebDriver driver;

    @Before
    public void setup() {
        driver = new ChromeDriver();
    }

    @Test
    public void testUserLoginFlow() {
        driver.get("http://localhost:8080/login");
        
        driver.findElement(By.id("email")).sendKeys("test@example.com");
        driver.findElement(By.id("password")).sendKeys("password123");
        driver.findElement(By.id("submit")).click();
        
        wait.until(ExpectedConditions.presenceOfElementLocated(
            By.id("dashboard"));
        
        assertTrue(driver.getCurrentUrl().contains("/dashboard"));
    }
}

Характеристики:

• Самые медленные (минуты)
• Тестируют весь стек: frontend + backend + БД
• Используют реальный браузер (Selenium, Playwright)
• Проверяют пользовательские сценарии
• Хрупкие (зависят от DOM, сетевых задержек)
• Запускаются редко (перед release, в CI)

4. Дополнительные уровни

Компонентные тесты (Component tests)

• Тестируют отдельный компонент (например, REST controller)
• С mock зависимостями

@RunWith(SpringRunner.class)
@WebMvcTest(UserController.class)
public class UserControllerTest {
    @Autowired
    private MockMvc mockMvc;
    
    @MockBean
    private UserService userService;

    @Test
    public void testGetUser() throws Exception {
        when(userService.getUser(1L))
            .thenReturn(new User(1L, "John"));
        
        mockMvc.perform(get("/users/1"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.name").value("John"));
    }
}

API тесты (Contract tests)

• Проверяют контракт между сервисами
• Используют Pact, Spring Cloud Contract

Метрики качества

• Code Coverage — % кода, покрытого тестами (целевое значение 80-90%)
• Test Coverage — % требований, покрытых тестами
• Test Execution Time — скорость выполнения тестов
• Bug Detection Rate — количество найденных багов

Рекомендации

1. Начинать с unit тестов для бизнес-логики
2. Добавлять интеграционные тесты для критических путей
3. E2E тесты только для ключевых пользовательских сценариев
4. Использовать CI/CD для автоматического запуска тестов
5. Поддерживать баланс между скоростью и покрытием