JavaRush /Курсы /Модуль 5. Spring /Лекция 131: Введение в тестирование: зачем это нужно

Лекция 131: Введение в тестирование: зачем это нужно

Модуль 5. Spring
14 уровень , 0 лекция
Открыта

Представьте себе мир, где разработчики пишут код, и он всегда работает идеально. Кажется фантастикой? Увы, это реальность, в которой ошибки неизбежны. И наша задача — не только создать красивый код, но и удостовериться, что он работает так, как ожидается.

Основные цели тестирования:

  1. Снижение вероятности багов. Даже опытный разработчик может допустить ошибку. Тесты помогают обнаруживать и устранять их ещё до того, как код попадёт в продакшн.
  2. Обеспечение качества приложения. Приложение должно вести себя предсказуемо. Никто не хочет, чтобы кнопка "оформить заказ" внезапно начала удалять пользователей.
  3. Уверенность в изменениях. Когда вы добавляете новую функциональность, тесты позволяют убедиться, что старый код продолжает работать корректно.
  4. Экономия времени на ручное тестирование. Если каждый раз проверять приложение вручную, можно быстро устать. Тесты автоматизируют этот процесс.
Fun fact: Первым программным "багом" был мотылёк, застрявший в релейном компьютере Harvard Mark II в 1947 году. Мы тестируем код, чтобы избежать своих "мотыльков".

Виды тестирования

Теперь давайте разберёмся, какие виды тестирования существуют и для чего они нужны.

Unit-тесты

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

Интеграционные тесты

  • Проверяют, как разные компоненты приложения работают вместе.
  • Здесь мы взаимодействуем с реальными ресурсами, такими как базы данных или внешние API.
  • Они менее изолированы, чем Unit-тесты, но дают представление о реальной работе системы.

Функциональные тесты

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

Системные тесты

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

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

Для организации тестов часто используют пирамиду тестирования:


/ Functional Tests \
/---------------------\
/  Integration Tests   \
/-----------------------\
/      Unit Tests        \
  • Основа пирамиды — Unit-тесты (~70% тестов). Они самые дешёвые и быстрые, поэтому их больше всего.
  • Средний уровень — Интеграционные тесты (~20%). Они проверяют взаимодействие компонентов.
  • Верхушка пирамиды — Функциональные тесты (~10%). Их сложнее настроить, поэтому их пишут меньше.

Пирамида подчиняется принципу быстрота-качество-затраты. Чем выше по пирамиде, тем больше усилий нужно, но тем обширнее тестируется приложение.


Где и когда мы пишем тесты?

Чем раньше, тем лучше

Чем раньше обнаружена ошибка, тем дешевле её исправить. Если баг обнаружен уже в продакшне, это затрудняет его исправление и может негативно повлиять на пользователей.

Вот почему важно писать тесты сразу при разработке нового функционала. Такой подход называется TDD — Test Driven Development (разработка через тестирование). Но об этом мы поговорим подробнее в следующих лекциях.

Правильный момент

  • Unit-тесты пишутся в процессе разработки конкретного метода или класса.
  • Интеграционные тесты создаются после завершения интеграции всех частей функционала.
  • Функциональные тесты добавляются на последнем этапе тестирования, перед выпуском в продакшн.

Реальная польза от тестов. А оно точно нужно?

Возможно, кто-то из вас уже задаётся вопросом: "А разве нельзя обойтись без тестов? Всё равно же QA всё проверит". Хороший вопрос! Давайте разберёмся.

  1. QA-тестеры найдут дефекты в приложении, но их задача — проверять готовый продукт. Автоматизированные тесты помогают разработчикам обнаружить ошибки на более ранних этапах.
  2. Тесты снижают риск. Вы уверены, что изменение в одной части кода не сломает другую. Например, вы поменяли логику работы API, и ваш Unit-тест сразу сообщит, если где-то допущена ошибка.
  3. Повышение доверия. Для командной разработки наличие тестов позволяет всем участникам команды быть уверенными в стабильности кода.

Глобальная картинка

Представьте большой проект с несколькими командами разработчиков. Каждый пишет свой функционал, вносит изменения и фиксит баги. Но как убедиться, что приложение в итоге работает как надо? Ответ очевиден: через тестирование. Это как страховка для разработчиков, где вы получаете уверенность, что всё идёт по плану.

Что мы узнали сегодня:

  • Тесты — необходимая часть процесса разработки, и они экономят время на поиске багов.
  • Существует несколько видов тестов, от Unit-тестов до функциональных.
  • Пирамида тестирования помогает распределить усилия: больше Unit-тестов, меньше функциональных.
  • Тесты не только про баги, но и про уверенность в качестве продукта.

В следующих лекциях мы погрузимся в практическую реализацию тестирования. Мы начнём с написания простых Unit-тестов с использованием JUnit 5 и познакомимся с мощными библиотеками, такими как Mockito, а затем перейдём к интеграционным тестам. Готовьтесь к интересным примерам и практике!

Комментарии
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ