Зачем нужны тесты?

Зачем нужны тесты?

Тесты - это один из самых важных инструментов в разработке. Я убедился в этом на протяжении своей 10+ летней карьеры. Без тестов проект очень быстро становится хрупким и непредсказуемым.

1. Гарантия корректности (Correctness)

Тест проверяет, что код работает правильно:

@Test
void shouldCalculatePriceWithDiscount() {
    // Гарантирует, что скидка считается правильно
    ShoppingCart cart = new ShoppingCart();
    cart.addItem(new Product("Item", 100.0));
    
    // Применяем скидку 10%
    double totalPrice = cart.calculateTotal(0.10);
    
    // Ожидаем 90
    assertEquals(90.0, totalPrice, 0.01);
}

// Если я случайно напишу:
// double discount = amount * 1.1;  // Вместо *0.9
// Тест сразу падёт и я это узнаю!

2. Обнаружение регрессий (Regression Prevention)

Когда я меняю старый код, тесты убеждают меня, что я ничего не сломал:

// Старая версия работает
public int calculateBonus(int salary) {
    return salary / 10;  // 10% бонус
}

// Я переписал для оптимизации
public int calculateBonus(int salary) {
    return salary / 100;  // Ошибка! Забыл изменить делитель
}

// Но есть тест:
@Test
void shouldCalculateBonus10Percent() {
    assertEquals(5000, calculateBonus(50000));
}

// Тест падает! Я сразу это вижу и исправляю

3. Документация кода

Тесты показывают, как использовать класс:

// Вместо скучного JavaDoc
/**
 * Переводит юзера в premium
 * @param userId идентификатор пользователя
 * @throws UserNotFoundException если юзер не найден
 */

// Тест показывает точное использование
@Test
void shouldUpgradeUserToPremium() {
    // 1. Создаём юзера
    User user = userRepository.save(new User("john@example.com"));
    
    // 2. Переводим в premium
    userService.upgradeToPremium(user.getId());
    
    // 3. Проверяем результат
    User upgraded = userRepository.findById(user.getId());
    assertTrue(upgraded.isPremium());
}

// Просто прочитав тест, я понимаю как это работает

4. Дизайн кода (Design Tool)

Написание теста первым (TDD) помогает спроектировать хороший код:

// Плохой дизайн (объект делает слишком много)
public class UserManager {
    public void createUserAndSendEmail(String email) {
        // Создание юзера
        User user = new User(email);
        userRepository.save(user);
        
        // Отправка email
        emailService.send("Welcome!", email);
        
        // Логирование
        logger.info("User created: " + email);
    }
}

// Тест будет сложный:
@Test
void shouldCreateUserAndSendEmail() {
    // Нужно мокировать БД
    // Нужно мокировать email сервис
    // Нужно мокировать logger
    // Тест становится хрупким
}

// TDD подсказывает разделить на части:
public class UserService {
    private UserRepository repository;
    
    public User createUser(String email) {
        return repository.save(new User(email));
    }
}

public class WelcomeEmailService {
    private EmailService emailService;
    
    public void sendWelcomeEmail(User user) {
        emailService.send("Welcome!", user.getEmail());
    }
}

// Теперь каждый тест простой и понятный
@Test
void shouldCreateUser() {
    User user = userService.createUser("john@example.com");
    assertEquals("john@example.com", user.getEmail());
}

@Test
void shouldSendWelcomeEmail() {
    welcomeEmailService.sendWelcomeEmail(user);
    verify(emailService).send("Welcome!", "john@example.com");
}

5. Уверенность при рефакторинге (Refactoring Confidence)

Тесты дают мне уверенность менять код:

// Старая реализация (медленная)
public List<User> getAllActiveUsers() {
    return userRepository.findAll().stream()
        .filter(User::isActive)
        .collect(Collectors.toList());  // Загружает всех пользователей!
}

// Оптимизация в БД
public List<User> getAllActiveUsers() {
    return userRepository.findAllActive();  // SQL WHERE active = true
}

// Но есть 50 тестов, которые используют этот метод!
// Я могу менять реализацию не боясь
// Если тесты падают - значит я что-то сломал

6. Обнаружение edge cases

Добрые тесты обнаруживают граничные случаи:

// Функция делит на число
public int divide(int a, int b) {
    return a / b;
}

// Плохо: я забыл проверить b == 0
// Тест обнаруживает это
@Test
void shouldHandleDivisionByZero() {
    assertThrows(ArithmeticException.class, () -> {
        divide(10, 0);
    });
}

// Или я должен обработать это явно
public int divide(int a, int b) {
    if (b == 0) {
        throw new IllegalArgumentException("Divisor cannot be zero");
    }
    return a / b;
}

7. Скорость разработки (Velocity)

На первый взгляд, написание тестов замедляет разработку. Но на самом деле это экономит время:

Без тестов:
- Неделя 1: Написал код быстро ✓
- Неделя 2: Баг в production ✗
- Неделя 3: Ловлю баги и пишу hotfixes ✗
- Неделя 4: Всё ещё не работает ✗
- Итого: 4 недели

С тестами:
- Неделя 1: Пишу тесты (медленнее)
- Неделя 2: Код работает, баги в production редкие
- Неделя 3: Рефакторю без страха
- Неделя 4: Добавляю новые фичи (старый код не ломается)
- Итого: 4 недели, но качество лучше в 10 раз

8. Командная работа

Тесты помогают команде не ломать друг другу код:

Алиса пишет UserService
Боб пишет OrderService и хочет использовать UserService

Без тестов:
- Боб не знает, как UserService должен работать
- Боб вызывает методы неправильно
- Алиса меняет UserService
- Боб кричит: "Ты сломал мой код!"

С тестами в UserService:
- Боб смотрит тесты и видит примеры использования
- Боб использует UserService правильно
- Алиса может менять реализацию (но не интерфейс)
- Если она нарушит контракт, тесты упадут

9. Спокойно спать (Peace of Mind)

Этот психологический аспект важен:

Без тестов:
- Я боюсь менять код
- Я боюсь деплоить в production
- Я проверяю вручную (отнимает время)
- Я всё равно упускаю баги

С хорошими тестами:
- Я уверен в коде
- Я могу деплоить с уверенностью
- CI/CD запускает тесты автоматически
- Баги редкие

10. Качество production кода

Проекты с хорошим покрытием тестами имеют:

• Меньше багов (статистически доказано)
• Легче добавлять новые фичи
• Легче менять архитектуру
• Легче находить ответственных за баги

Типы тестов и когда их использовать

// Unit тесты (быстрые, много)
public class UserServiceTest {
    @Test
    void shouldCreateUser() { }
}

// Integration тесты (медленнее, меньше)
public class UserRepositoryIntegrationTest {
    @Test
    void shouldSaveAndFindUser() { }
}

// E2E тесты (очень медленные, мало)
public class UserRegistrationE2ETest {
    @Test
    void shouldRegisterUserThroughWebUI() { }
}

// Пирамида тестов:
//        /\
//       /  \ E2E тесты (少)
//      /____\
//     /      \ Integration (中)
//    /________\
//   /          \ Unit тесты (多)
//  /____________\

Резюме

Тесты нужны потому что они:

1. Гарантируют корректность - код работает как надо
2. Предотвращают регрессии - старый код не ломается
3. Документируют код - пример использования
4. Улучшают дизайн - заставляют писать лучший код
5. Дают уверенность - можно менять и рефакторить
6. Находят edge cases - граничные случаи
7. Ускоряют разработку - меньше времени на отладку
8. Помогают команде - общий стандарт качества
9. Дают спокойствие - можно спать спокойно
10. Улучшают quality - меньше production bagов

Любой профессиональный разработчик пишет тесты. Это не опция, это необходимость.