Ответ
Тестирование структурировано по уровням (пирамида тестирования) и целям. Вот ключевые виды:
По уровню изоляции (Пирамида)
-
Модульные тесты (Unit Tests)
- Цель: Проверить корректность работы отдельной единицы кода (метода, класса) в полной изоляции.
- Инструменты: JUnit, TestNG, Mockito (для заглушек зависимостей).
- Пример:
@Test void shouldReturnSumOfTwoNumbers() { Calculator calc = new Calculator(); int result = calc.add(2, 3); assertEquals(5, result); // Проверяем только логику метода add }
-
Интеграционные тесты (Integration Tests)
- Цель: Проверить взаимодействие нескольких модулей или систем (БД, внешние API, другие сервисы).
- Инструменты: Spring Boot Test (
@SpringBootTest), Testcontainers (для поднятия реальных БД в Docker). - Фокус: Корректность интеграции, транзакции, конфигурация.
-
Системные / End-to-End (E2E) тесты
- Цель: Проверить работу всего приложения целиком с точки зрения конечного пользователя.
- Инструменты: Selenium, Cypress, Playwright (для UI), REST Assured (для API).
- Фокус: Полные пользовательские сценарии.
По целям и свойствам
-
Функциональные тесты
- Проверяют соответствие функциональным требованиям ("что система делает"). Могут быть на любом уровне (Unit, E2E).
-
Нефункциональные тесты
- Нагрузочное (Load) и стресс-тестирование: Проверка производительности под нагрузкой (JMeter, Gatling).
- Тестирование безопасности (Security): Поиск уязвимостей.
-
Поддерживающие виды по стратегии
- Дымовое (Smoke): Быстрая проверка основных функций после сборки.
- Регрессионное (Regression): Проверка, что новые изменения не сломали существующий функционал.
- Приёмочное (Acceptance): Проверка соответствия бизнес-требованиям, часто заказчиком.
Практическое правило (Пирамида): Писать много быстрых и дешёвых unit-тестов, меньше интеграционных и ещё меньше медленных и дорогих E2E-тестов.
Ответ 18+ 🔞
А, ну вот, классика жанра подъехала — пирамида тестирования! Это ж как в том анекдоте про слона: каждый трогает за разное место, а потом охуевает, что у него хобот. Так и тут — если ты только за E2E-тесты уцепился, то про unit-тесты забудешь, и наоборот. Слушай, разложу по полочкам, но с приправами.
По степени изоляции, или «Кто с кем спит»
-
Юнит-тесты (Unit Tests)
- Суть: Это когда ты берёшь один мелкий кусочек кода — метод, функцию — и начинаешь его ебашить в полной изоляции. Как будто он один во всей вселенной. Все его дружки-зависимости — нахуй, подменяем их заглушками (моками).
- Чем тыкать: JUnit, TestNG, а для создания этих самых заглушек — Mockito, чтобы не тащить за собой всю вселенную.
- Пример, чтобы не быть пиздаболом:
@Test void shouldReturnSumOfTwoNumbers() { Calculator calc = new Calculator(); // Чистый, как слеза младенца, объект int result = calc.add(2, 3); assertEquals(5, result); // Проверяем ТОЛЬКО логику метода add. Никаких баз данных, никаких соседей по общежитию. } - Философия: Если этот мелкий пиздёныш работает неправильно, то вся конструкция на нём — пиздец.
-
Интеграционные тесты (Integration Tests)
- Суть: А вот тут уже начинается веселье. Проверяем, как наши модули ебутся друг с другом. Работает ли код с реальной (или почти реальной) базой данных? Шлёт ли он запросы куда надо? Не обосрётся ли на конфигурации?
- Чем тыкать: Spring Boot Test (
@SpringBootTest), а для особо извращённых случаев — Testcontainers, который поднимет настоящую PostgreSQL в Docker, и ты будешь плакать, но зато знать, что всё работает. - Фокус: Не «что делает», а «как общается». Транзакции, сетевые вызовы, сериализация — вот это всё.
-
Сквозные тесты (E2E)
- Суть: Это уже высший пилотаж, вид с балкона. Берём всё приложение целиком — фронт, бэк, базу, кеш, всё нахуй — и гоняем по нему полные пользовательские сценарии. Как будто реальный юзер, только тупой и запрограммированный.
- Чем тыкать: Для веба — Selenium, Cypress, Playwright (чтобы кнопки тыкать). Для API — REST Assured.
- Фокус: «А работает ли эта ваша фигня в принципе?». Медленные, хрупкие, но иногда без них — никуда.
А теперь по тому, НАХУЯ мы это вообще делаем
-
Функциональные тесты
- Самые понятные. Отвечают на вопрос: «А делает ли система то, что от неё хотят?». Могут быть на любом уровне — от юнита (проверяем, что метод считает скидку) до E2E (проверяем, что можно купить тапки).
-
Нефункциональные тесты (или «А как оно под нагрузкой, а?»)
- Нагрузочные/стресс-тесты: Это когда ты наваливаешь на систему овердохуища виртуальных пользователей и смотришь, не ляжет ли она с криком «мамочка». Инструменты — JMeter, Gatling. Без этого — как без штанов на морозе, можно и проебаться.
- Тестирование безопасности: Поиск дыр, через которые к тебе могут залезть. Не сделаешь — сам станешь тем самым «пидором шерстяным», которого взломали через SQL-инъекцию.
-
Вспомогательные виды, или «Стратегия на каждый день»
- Дымовые (Smoke): После каждой сборки — быстренько, по верхам. «Запускается? Не падает на главной? База отвечает?» — и дальше можно пить кофе.
- Регрессионные (Regression): Главный страх любого разработчика. Добавил новую фичу — не разъебало ли старые? Вот для этого они и нужны.
- Приёмочные (Acceptance): Самые важные. Соответствует ли результат бизнес-ожиданиям? Часто это уже не просто код, а какая-то херня вроде Cucumber, где тесты пишут почти человеческим языком.
А теперь золотое правило, ёпта! Представь себе пирамиду.
- Основание (широкое, много): Быстрые, дешёвые, надёжные юнит-тесты. Их должно быть дохуя. Они — твоя подушка безопасности.
- Середина (поменьше): Интеграционные тесты. Медленнее, сложнее, но тоже нужны.
- Верхушка (совсем чуть-чуть): Тяжёлые, капризные E2E-тесты. Их мало, они как спецназ — для самых важных сценариев.
Если у тебя пирамида перевёрнута и ты пишешь в основном E2E — ты, прости, мудак. Потому что такая тест-сьюта будет работать полдня, а сломаться от смены цвета кнопки. Держи баланс, и будет тебе счастье.