Ответ
Интеграционный тест проверяет взаимодействие нескольких модулей или компонентов приложения. В отличие от юнит-тестов, которые тестируют изолированные части кода, интеграционные тесты проверяют, как эти части работают вместе.
Пример для фронтенда (React + Jest):
// Тестируем, что компонент корректно отображает данные из API
test('renders user data', async () => {
const mockData = { name: 'John Doe' };
jest.spyOn(global, 'fetch').mockResolvedValue({
json: () => Promise.resolve(mockData)
});
render(<UserProfile userId="1" />);
await waitFor(() => {
expect(screen.getByText('John Doe')).toBeInTheDocument();
});
});Ключевые особенности:
- Проверяют цепочки взаимодействий (API ↔ компонент, компонент ↔ хранилище)
- Медленнее юнит-тестов, но быстрее E2E
- Часто используют моки для внешних зависимостей
- Охватывают критически важные сценарии работы приложения
Ответ 18+ 🔞
А, интеграционные тесты, ну это же классика, блядь! Это когда ты уже не просто одну функцию пингуешь, а смотришь, как вся эта ваша конструкция из говна и палок начинает работать вместе. Как в оркестре, сука: каждый вроде на репетиции свою партию выёбывает, а как вместе — какофония, пиздец!
Представь: у тебя есть кнопка, есть хранилище, есть какой-нибудь API на бэкенде, который, как последняя шлюха, может и ответить, а может и лечь. Юнит-тест проверит, что кнопка, будучи пнута, вызывает ровно ту функцию, которую ты ожидаешь. А интеграционный тест — это когда ты эту кнопку нажимаешь и смотришь, долетит ли запрос до сервера, вернётся ли ответ, запишется ли это всё в стор, и не превратится ли твой интерфейс в тыкву на каждом из этих этапов.
Вот смотри на этот код, ёпта:
// Тестируем, что компонент корректно отображает данные из API
test('renders user data', async () => {
const mockData = { name: 'John Doe' };
jest.spyOn(global, 'fetch').mockResolvedValue({
json: () => Promise.resolve(mockData)
});
render(<UserProfile userId="1" />);
await waitFor(() => {
expect(screen.getByText('John Doe')).toBeInTheDocument();
});
});Видишь, что происходит? Мы не тестируем фетч отдельно и не тестируем рендер отдельно. Мы говорим: «Эй, сука, компонент UserProfile! Ты должен взять айдишник, сходить за данными и показать их мне!». И мы подменяем настоящий fetch на свою заглушку, чтобы не зависеть от того, горит ли сейчас бэкенд или нет. Мы проверяем цепочку: «компонент смонтировался -> пошёл запрос -> получил ответ -> отрисовал данные». Если где-то сбой — тест падает, и ты понимаешь, что твоя интеграция разъебалась.
И да, они, конечно, медленнее юнитов, потому что там уже браузерное окружение, рендер и прочая муть. Но это ещё не тот адский замедленный танец, как E2E, где реальный браузер всё делает. Это как бы золотая середина, блядь. Не слишком быстро, не слишком медленно, но покрывает самые важные сценарии, без которых пользователь просто получит в лицо белую страницу с ошибкой. И моки тут — твои лучшие друзья, потому что без них ты будешь тестировать не свою логику, а стабильность интернета в офисе, а это, прости, пиздец как ненадёжно.