TDD: ano ito, mga prinsipyo ng pagsubok at metodolohiya

Ano ang TDD?

Test-Driven Development — ay isang praktika ng pag-develop ng software kung saan ang mga automated test ay tumutukoy sa pagsusulat ng production code. Hindi tulad ng tradisyonal na approach kung saan ang code ay isinusulat at pagkatapos ay sinusubok, binabaliktad ng TDD ang pagkakasunod-sunod: una isinusulat ang test, pagkatapos ay ang code na pumapasa sa test na ito.

Ang nagtatag ng TDD ay itinuturing na Kent Beck, na bumuo ng praktikang ito noong huling bahagi ng 1990s sa loob ng metodolohiyang Extreme Programming (XP). Sa aklat na “Test-Driven Development: By Example” (2002) inilarawan ni Beck ang limang patakaran ng TDD na naging kanonikal: sumulat ng test bago ang production code, sumulat ng eksaktong dami ng code na kailangan para maipasa ang test, at mag-refactor pagkatapos ng bawat cycle.

Mga pangunahing prinsipyo ng TDD

Unang prinsipyo — tinutukoy ng test ang interface. Ang developer ay napipilitang isipin kung paano gagamitin ang component bago isipin kung paano ito ipinatupad. Ito ay bumubuo ng malinis na API mula pa sa simula.

TDD bilang technique ng disenyo

Ikalawang prinsipyo — minimal na implementasyon. Kapag naisulat na ang test, sumusulat ang developer ng eksaktong dami ng production code na kailangan para maipasa ito — wala nang dagdag na linya. Ito ay pumipigil sa maagang abstraction at labis na pagiging kumplikado na tinatawag ni Martin Fowler na Speculative Generality.

Pagkakaiba ng TDD sa karaniwang pagsubok

Ang pangunahing pagkakaiba sa pagitan ng TDD at pagsubok “pagkatapos ng katotohanan” — disiplina sa pagkakasunod-sunod. Sa TDD, hindi lamang sinusuri ng test ang code — ginagabayan nito ang istraktura nito. Ayon sa pananaliksik ng Microsoft Research (Nagappan et al., 2008), ang mga team na nag-aaplay ng TDD ay nagpapakita ng pagbawas sa density ng depekto ng 40–90% kumpara sa mga team na gumagamit ng tradisyonal na approach.

Ang Red-Green-Refactor cycle

Ang Red-Green-Refactor cycle — ay isang tatlong-hakbang na pagkakasunod-sunod na inuulit para sa bawat bagong test. Red: sumulat ng test na hindi pumapasa. Green: sumulat ng minimal na code para maipasa ang test. Refactor: pagbutihin ang code nang hindi binabago ang pag-uugali nito.

Phase Red: pagsusulat ng bagsak na test

Ang developer ay sumusulat ng test na sumusuri sa hindi pa naipapatupad na functionality. Sa yugtong ito, ang test ay dapat bumagsak — ito ay nagpapatunay na ang test ay talagang sumusuri ng isang bagay. Sa Android development environment, ang JUnit 5 framework ay nagpapakita ng pulang indikasyon para sa mga bagsak na test, na nagbigay ng pangalan sa phase na ito.

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

Phase Green: minimal na implementasyon

Sa yugtong ito, isinusulat ang minimal na production code na sapat para maipasa ang test. Walang redundancy — tanging kung ano ang kailangan para sa berdeng indikasyon. Kung ang implementasyon ay maaaring maging constant — hayaan itong maging constant. Ang refactoring ay magaganap sa susunod na hakbang kapag lumitaw ang mga bagong test.

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

Phase Refactor: pagpapabuti nang walang panganib

Ang berdeng test ay seguro para sa refactoring. Maaaring isulat muli ng developer ang implementasyon, i-optimize ang performance, o pahusayin ang pagiging madaling basahin, na may katiyakan na agad na makikita ng test ang anumang paglihis mula sa inaasahang pag-uugali. Sa mobile development sa Android, ang phase na ito ay lalong mahalaga para sa paghihiwalay ng mga karaniwang interface at pagbawas ng pagdodoble ng code.

Mga Bentahe ng TDD sa mobile development

Ang paglalapat ng TDD sa mga mobile project ay nagbibigay ng nasusukat na mga bentahe, na kinumpirma pareho ng akademikong pananaliksik at ng praktika ng nangungunang mga studio sa pag-develop.

Pagbawas ng density ng depekto

Ang pananaliksik ng IBM (Bhat & Nagappan, 2006) sa apat na industrial project ay nagpakita na ang mga team na gumagamit ng TDD ay gumagawa ng 40% mas kaunting depekto kumpara sa mga katulad na team na nagtatrabaho nang tradisyonal. Para sa mobile development, kung saan ang gastos ng pag-aayos ng bug pagkatapos ng release sa Google Play ay mas mataas kaysa sa yugto ng pagsusulat ng code, ang metrik na ito ay kritikal.

Dokumentasyon ng code sa pamamagitan ng mga test

Ang mga test na isinulat ayon sa TDD ay nagsisilbing buhay na dokumentasyon ng API. Ang developer na pumapasok sa proyekto ay maaaring magbasa ng mga test at maunawaan kung paano dapat gamitin ang bawat component. Ito ay lalong mahalaga sa mga kondisyon ng mataas na pagbabago ng team — isang karaniwang problema ng mga mobile studio.

Kumpiyansang refactoring

Ang saklaw ng code ng mga test na lumalampas sa 90% ay nagpapahintulot sa mga developer na magsagawa ng refactoring nang walang takot na masira ang isang bagay. Ang Google sa aklat nitong “Software Engineering at Google” (2020) ay tinatawag ang test coverage na pangunahing salik na nagpapahintulot na mapanatiling malinis ang codebase sa mga proyektong may milyong linya ng code.

Mga tool at framework para sa TDD

Ang ekosistema ng TDD sa mobile development ay may kasamang mga tool para sa unit testing, mocking, at pagsusuri ng mga UI component — para sa parehong Android at iOS.

Pagpili ng framework para sa Android

Para sa Android projects sa Kotlin, ang standard stack ay may kasamang JUnit 5 + MockK. Ang MockK ay mas pinipili kaysa Mockito dahil sinusuportahan nito ang Kotlin first-class functions — sealed class, coroutine, at suspend-function nang walang karagdagang configuration.

Mga tool para sa iOS

Sa iOS development, ang TDD ay ipinatutupad sa pamamagitan ng XCTest — ang built-in na framework ng Apple na nagbibigay ng assertions, test classes, at integration sa CI/CD sa pamamagitan ng Xcode Server o GitHub Actions. Para sa mocking sa iOS, ginagamit ang mga library na Cuckoo at OHHTTPStubs.

Mga halimbawa ng code ng TDD sa Kotlin

Tingnan natin ang isang tunay na TDD scenario sa Kotlin para sa Android — pagsubok ng user repository. Una nating isulat ang test, pagkatapos — ang implementasyon na pumapasa sa test na ito.

Hakbang 1: test para sa 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) }
    }
}

Hakbang 2: minimal na implementasyon

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
    }
}

Hakbang 3: test para sa caching na may offline mode

Pagkatapos maipasa ang unang test, nagdadagdag tayo ng pangalawa — sinusuri ang pag-uugali sa error sa network. Ngayon, tinutukoy ng test na kapag bumagsak ang API, ang repository ay dapat magbalik ng data mula sa cache.

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)
}

Mga karaniwang pagkakamali sa pagpapatupad ng TDD

Ang paglipat sa TDD ay may kasamang mga karaniwang pagkakamali na maaaring magpawalang-bisa sa lahat ng bentahe ng metodolohiya. Ang pag-unawa sa mga patibong na ito ay tumutulong sa mga team na ipatupad ang praktika nang mas epektibo.

Masyadong malalaking test

Una at pinakakaraniwang anti-pattern — pagsubok ng masyadong maraming functionality sa isang test. Ang test ay dapat sumuri ng eksaktong isang assertion (isang asersyon). Kung bumagsak ang test, dapat malaman ng developer kung ano ang eksaktong nasira nang walang karagdagang debugging.

Hindi pagpansin sa pulang phase

Pangalawang pagkakamali — pagsusulat ng test na pumapasa mula sa simula. Kung ang test ay hindi naging pula kahit isang beses, walang katiyakan na ito ay sumusuri ng kahit ano. Patakaran: huwag magtiwala sa test na hindi mo nakita na bumagsak.

Paglaktaw sa refactoring

Pangatlong karaniwang pagkakamali — pagtigil sa berdeng phase. Refactoring ay hindi opsyonal na yugto, kundi mandatoryong bahagi ng cycle. Kung wala ito, ang codebase ay nagde-degrade, ang mga test ay nagiging marupok, at ang mga bentahe ng TDD ay nawawala.

• Pagsubok ng implementasyon, hindi ng pag-uugali — ang mga test ay nakatali sa mga detalye at nasisira sa bawat refactoring
• Kawalan ng mga test para sa edge cases — mga walang laman na listahan, null values, boundary conditions ay nananatiling hindi nasasaklaw
• Hindi pagpansin sa bilis ng mga test — mabagal na test ay nagpapabagal sa feedback loop at pumapatay sa disiplina ng TDD