Что было с тестами в команде

Организация тестирования: от хаоса к зрелым процессам

В моей практике состояние тестирования в командах проходило через несколько этапов эволюции, которые напрямую коррелировали со зрелостью процессов разработки.

Начальный этап: тестирование как "роскошь"

В стартапах и на ранних этапах проектов тестирование часто воспринималось как нечто второстепенное:

• Unit-тесты писались энтузиастами — обычно 1-2 разработчика в команде
• Полное отсутствие CI/CD — тесты запускались вручную перед мержем
• Тестирование UI было рутиной — QA-инженеры выполняли регрессионное тестирование вручную
• Покрытие кода было низким (< 30%), что приводило к частым регрессиям

// Пример типичного "обезьяньего" теста того периода
@Test
fun `test login success`() {
    val viewModel = LoginViewModel()
    viewModel.login("test", "password")
    // Никаких assert'ов, только проверка что не упало
}

Переломный момент: боль от багов в продакшене

Ситуация менялась после критических инцидентов:

1. Критический баг в продакшене приводил к финансовым потерям
2. Длительные циклы ручного тестирования замедляли выпуск фич
3. Рефакторинг становился рискованным без покрытия тестами

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

Мы внедряли комплексный подход:

Архитектурные изменения:

• Переход к Clean Architecture и MVVM/MVI для лучшей тестируемости
• Внедрение Dependency Injection (Dagger/Hilt) для мокирования зависимостей
• Разделение бизнес-логики и платформозависимого кода

Тестовая пирамида:

Unit Tests (70%) - быстрые, изолированные тесты бизнес-логики
Integration Tests (20%) - тестирование взаимодействия компонентов
UI Tests (10%) - инструментальные тесты экранов

Технологический стек:

• JUnit 5 и Kotest для unit-тестирования
• MockK или Mockito для мокирования
• Espresso и UI Automator для UI-тестов
• Robolectric для тестирования Android-компонентов без эмулятора

// Пример современного unit-теста с Kotest и MockK
class LoginViewModelTest : DescribeSpec({
    describe("LoginViewModel") {
        val authRepository = mockk<AuthRepository>()
        val dispatcher = TestCoroutineDispatcher()
        val viewModel = LoginViewModel(authRepository, dispatcher)
        
        beforeEach {
            clearAllMocks()
        }
        
        it("should emit success state on valid credentials") {
            // Given
            coEvery { authRepository.login("user", "pass123") } returns Result.Success(USER_TOKEN)
            
            // When
            viewModel.login("user", "pass123")
            
            // Then
            viewModel.state.test {
                val loadingState = awaitItem()
                loadingState shouldBe LoginState.Loading
                
                val successState = awaitItem()
                successState shouldBe LoginState.Success
            }
        }
    }
})

CI/CD и автоматизация

Ключевые улучшения:

• Настройка Git hooks для запуска тестов перед коммитом
• Полноценный CI/CD pipeline (GitHub Actions, GitLab CI, Bitrise)
• Проверка покрытия кода с минимальными требованиями (обычно 70-80%)
• Параллельный запуск тестов для уменьшения времени выполнения
• Отчеты о покрытии и статический анализ (Detekt, ktlint)

Культурные изменения

Самые важные трансформации происходили в менталитете команды:

• Тесты как часть Definition of Done — без тестов PR не мержится
• Pair programming при написании сложной бизнес-логики
• Регулярные code review с акцентом на тестируемость кода
• Обучение и knowledge sharing по теме тестирования

Результаты

После внедрения этих практик:

• Количество багов в продакшене снизилось на 60-70%
• Скорость разработки увеличилась благодаря уверенности при рефакторинге
• Onboarding новых разработчиков ускорился — тесты как документация
• Технический долг стал управляемым

Наиболее важный insight: тестирование — это не только про технологии, но в первую очередь про культуру разработки. Успех приходит когда каждый член команды внутренне принимает ценность тестов как страховки для будущих изменений, а не как бюрократическое требование.