TDD: що це, принципи тестування та методологія

Що таке TDD?

Test-Driven Development — це практика розробки програмного забезпечення, при якій автоматизовані тести визначають написання production-коду. На відміну від традиційного підходу, де код пишеться, а потім тестується, TDD перевертає послідовність: спочатку пишеться тест, потім код, який цей тест проходить.

Основоположником TDD вважається Kent Beck, який сформулював цю практику в кінці 1990-х років у рамках методології Extreme Programming (XP). У книзі «Test-Driven Development: By Example» (2002) Бек описав п'ять правил TDD, які стали канонічними: пиши тест до production-коду, пиши рівно стільки коду, скільки потрібно для проходження тесту, і рефактори після кожного циклу.

Ключові принципи TDD

Перший принцип — тест визначає інтерфейс. Розробник змушений думати про те, як компонент буде використовуватися, перш ніж думати про те, як він реалізований. Це формує чистий API з самого початку.

TDD як техніка проєктування

Другий принцип — мінімальна реалізація. Коли тест написаний, розробник пише рівно стільки production-коду, скільки потрібно для його проходження, — ні рядком більше. Це запобігає передчасній абстракції та надмірній складності, яку Martin Fowler називає Speculative Generality.

Відмінність TDD від звичайного тестування

Ключова відмінність між TDD і тестуванням «постфактум» — дисципліна послідовності. У TDD тест не просто перевіряє код — він спрямовує його структуру. За даними дослідження Microsoft Research (Nagappan et al., 2008), команди, що застосовують TDD, демонструють зниження щільності дефектів на 40–90% порівняно з командами, що використовують традиційний підхід.

Цикл Red-Green-Refactor

Цикл Red-Green-Refactor — це трикрокова послідовність, яка повторюється для кожного нового тесту. Red: написати тест, який не проходить. Green: написати мінімальний код, щоб тест пройшов. Refactor: покращити код без зміни його поведінки.

Фаза Red: написання тесту, що падає

Розробник пише тест, який перевіряє ще не реалізовану функціональність. На цьому етапі тест повинен впасти — це підтверджує, що тест дійсно щось перевіряє. У середовищі Android-розробки фреймворк JUnit 5 показує червону індикацію для тестів, що впали, що й дало назву фазі.

class CalculatorTest {
    fun testAddition() {
        val result = Calculator().add(2, 3)
        Assertions.assertEquals(5, result)
    }
}

Фаза Green: мінімальна реалізація

На цьому етапі пишеться мінімальний production-код, достатній для проходження тесту. Жодної надмірності — тільки те, що потрібно для зеленої індикації. Якщо реалізація може бути константою — нехай буде константою. Рефакторинг відбудеться на наступному кроці, коли з'являться нові тести.

class Calculator {
    fun add(a: Int, b: Int): Int {
        return a + b
    }
}

Фаза Refactor: покращення без ризику

Зелений тест — це страховка для рефакторингу. Розробник може переписати реалізацію, оптимізувати продуктивність або покращити читабельність, будучи впевненим, що тест негайно виявить будь-яке відхилення від очікуваної поведінки. У мобільній розробці на Android ця фаза особливо важлива для виділення спільних інтерфейсів і зменшення дублювання коду.

Переваги TDD у мобільній розробці

Застосування TDD у мобільних проєктах дає вимірювані переваги, підтверджені як академічними дослідженнями, так і практикою провідних студій розробки.

Зниження щільності дефектів

Дослідження IBM (Bhat & Nagappan, 2006) на чотирьох промислових проєктах показало, що команди, які використовують TDD, допускають на 40% менше дефектів порівняно з аналогічними командами, що працюють за традиційною схемою. Для мобільної розробки, де вартість виправлення багу після релізу в Google Play значно вища, ніж на етапі написання коду, ця метрика критична.

Документування коду через тести

Тести, написані за TDD, служать живою документацією API. Розробник, який приходить у проєкт, може прочитати тести та зрозуміти, як повинен використовуватися кожен компонент. Це особливо цінно в умовах високої плинності команди — типової проблеми мобільних студій.

Упевнений рефакторинг

Покриття коду тестами, що перевищує 90%, дозволяє розробникам проводити рефакторинг без страху щось зламати. Google у своїй книзі «Software Engineering at Google» (2020) називає тестове покриття ключовим фактором, що дозволяє підтримувати кодову базу в чистоті на проєктах з мільйонами рядків коду.

Інструменти та фреймворки для TDD

Екосистема TDD у мобільній розробці включає інструменти для unit-тестування, mocking та перевірки UI-компонентів — як для Android, так і для iOS.

Вибір фреймворку для Android

Для Android-проєктів на Kotlin стандартний стек включає JUnit 5 + MockK. MockK є кращим за Mockito, оскільки підтримує функції Kotlin першого класу — sealed class, корутини та suspend-функції — без додаткових налаштувань.

Інструменти для iOS

У iOS-розробці TDD реалізується через XCTest — вбудований фреймворк Apple, який надає assertions, тестові класи та інтеграцію з CI/CD через Xcode Server або GitHub Actions. Для mocking на iOS застосовуються бібліотеки Cuckoo та OHHTTPStubs.

Приклади коду з TDD на Kotlin

Розглянемо реальний сценарій TDD на Kotlin для Android — тестування репозиторію користувачів. Спочатку пишемо тест, потім — реалізацію, яка проходить цей тест.

Крок 1: тест для UserRepository

class UserRepositoryTest {
    private val api = mockk<UserApi>()
    private val dao = mockk<UserDao>()
    private val repo = UserRepository(api, dao)

    fun `when api returns user then cache and emit`() = runTest {
        val user = User(1, "Alice")
        coEvery { api.getUser(1) } returns user
        every { dao.insert(user) } returns Unit

        val result = repo.getUser(1)

        assertEquals(user, result)
        verify { dao.insert(user) }
    }
}

Крок 2: мінімальна реалізація

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Int): User {
        val user = api.getUser(id)
        dao.insert(user)
        return user
    }
}

Крок 3: тест для кешування з офлайн-режимом

Після проходження першого тесту додаємо другий — перевіряємо поведінку при помилці мережі. Тепер тест визначає, що при падінні API репозиторій повинен повернути дані з кешу.

fun `when api fails then return cached user`() = runTest {
    val cached = User(1, "Cached Alice")
    coEvery { api.getUser(1) } throws IOException()
    every { dao.getById(1) } returns cached

    val result = repo.getUser(1)

    assertEquals(cached, result)
}

Типові помилки при впровадженні TDD

Перехід на TDD пов'язаний з типовими помилками, які можуть звести нанівець усі переваги методології. Розуміння цих пасток допомагає командам впроваджувати практику ефективніше.

Занадто великі тести

Перший і найпоширеніший Anti-Pattern — тестування занадто великого обсягу функціональності в одному тесті. Тест повинен перевіряти рівно одне твердження (один assert). Якщо тест падає, розробник повинен знати, що саме зламалося, без додаткового налагодження.

Ігнорування червоної фази

Друга помилка — написання тесту, який спочатку проходить. Якщо тест не був червоним хоча б один раз, немає впевненості, що він взагалі щось перевіряє. Правило: ніколи не вір тесту, який ти не бачив таким, що падає.

Пропуск рефакторингу

Третя типова помилка — зупинка на зеленій фазі. Рефакторинг — це не опціональний, а обов'язковий етап циклу. Без нього кодова база деградує, тести стають крихкими, і переваги TDD втрачаються.

• Тестування реалізації, а не поведінки — тести прив'язуються до деталей і ламаються при кожному рефакторингу
• Відсутність тестів для edge-кейсів — порожні списки, null-значення, граничні умови залишаються непокритими
• Ігнорування швидкості тестів — повільні тести уповільнюють цикл зворотного зв'язку та вбивають дисципліну TDD