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

Какво е TDD?

Test-Driven Development — е практика за разработка на софтуер, при която автоматизираните тестове определят писането на продукционен код. За разлика от традиционния подход, при който кодът се пише, а след това се тества, TDD обръща последователността: първо се пише тестът, след това кодът, който преминава този тест.

За основател на TDD се смята Kent Beck, който формулира тази практика в края на 90-те години на XX век в рамките на методологията Extreme Programming (XP). В книгата „Test-Driven Development: By Example" (2002) Beck описва пет правила на TDD, които стават канонични: пиши теста преди продукционния код, пиши точно толкова код, колкото е необходимо за преминаване на теста, и рефакторирай след всеки цикъл.

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

Първият принцип — тестът определя интерфейса. Разработчикът е принуден да мисли за това как компонентът ще се използва, преди да мисли за това как е имплементиран. Това формира чист API от самото начало.

TDD като техника за проектиране

Вторият принцип — минимална имплементация. Когато тестът е написан, разработчикът пише точно толкова продукционен код, колкото е необходимо за преминаването му — нито ред повече. Това предотвратява преждевременната абстракция и прекомерната сложност, която 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: минимална имплементация

На този етап се пише минимален продукционен код, достатъчен за преминаване на теста. Без излишество — само това, което е необходимо за зелена индикация. Ако имплементацията може да бъде константа — нека бъде константа. Рефакторингът ще се случи на следващата стъпка, когато се появят нови тестове.

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 в мобилната разработка включва инструменти заединични тестове, mocking и проверка на UI компоненти — както за Android, така и за iOS.

Избор на рамка за Android

За Android проекти на Kotlin стандартният стек включва JUnit 5 + MockK. MockK е предпочитан пред Mockito, тъй като поддържа Kotlin функции от първи клас — sealed class, корутини и suspend-функции без допълнителна конфигурация.

Инструменти за iOS

В iOS разработката TDD се имплементира чрез XCTest — вградената рамка на Apple, която предоставя асерции, тестови класове и интеграция с 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 е съпроводен с типични грешки, които могат да анулират всички предимства на методологията. Разбирането на тези капани помага на екипите да въвеждат практиката по-ефективно.

Твърде големи тестове

Първият и най-разпространен анти-шаблон — тестване на твърде голям обем функционалност в един тест. Тестът трябва да проверява точно едно твърдение (една асерция). Ако тестът се провали, разработчикът трябва да знае какво точно се е счупило без допълнително дебъгване.

Игнориране на червената фаза

Втората грешка — писане на тест, който отначало преминава. Ако тестът не е бил червен поне веднъж, няма сигурност, че изобщо проверява нещо. Правило: никога не вярвай на тест, който не си виждал да се проваля.

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

Третата типична грешка — спиране на зелената фаза. Рефакторингът не е опционален, а задължителен етап от цикъла. Без него кодовата база деградира, тестовете стават крехки и предимствата на TDD се губят.

• Тестване на имплементацията, а не на поведението — тестовете се обвързват с детайли и се чупят при всеки рефакторинг
• Липса на тестове за гранични случаи — празни списъци, null стойности, гранични условия остават непокрити
• Игнориране на скоростта на тестовете — бавните тестове забавят цикъла на обратна връзка и убиват дисциплината TDD