TDD: What It Is, Testing Principles, and Methodology

What Is TDD?

Test-Driven Development is a software development practice where automated tests drive the writing of production code. Unlike the traditional approach where code is written and then tested, TDD reverses the sequence: first the test is written, then the code that passes the test.

The founder of TDD is Kent Beck, who formulated this practice in the late 1990s as part of the Extreme Programming (XP) methodology. In the book “Test-Driven Development: By Example” (2002), Beck described five rules of TDD that became canonical: write the test before production code, write just enough code to pass the test, and refactor after each cycle.

Key Principles of TDD

The first principle is the test defines the interface. The developer is forced to think about how the component will be used before thinking about how it is implemented. This shapes a clean API from the very beginning.

TDD as a Design Technique

The second principle is minimal implementation. When the test is written, the developer writes exactly as much production code as needed to pass it—not a line more. This prevents premature abstraction and excessive complexity, which Martin Fowler calls Speculative Generality.

How TDD Differs from Regular Testing

The key difference between TDD and post-hoc testing is the discipline of sequence. In TDD, the test does not just verify code—it guides its structure. According to a Microsoft Research study (Nagappan et al., 2008), teams applying TDD demonstrate a 40–90% reduction in defect density compared to teams using the traditional approach.

The Red-Green-Refactor Cycle

The Red-Green-Refactor cycle is a three-step sequence repeated for each new test. Red: write a test that does not pass. Green: write the minimum code to make the test pass. Refactor: improve the code without changing its behavior.

Red Phase: Writing a Failing Test

The developer writes a test that checks functionality not yet implemented. At this stage, the test must fail—this confirms that the test actually verifies something. In the Android development environment, the JUnit 5 framework shows a red indicator for failed tests, which gave the phase its name.

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

Green Phase: Minimal Implementation

At this stage, the minimal production code sufficient to pass the test is written. No redundancy—only what is needed for the green indicator. If the implementation can be a constant, let it be a constant. Refactoring will happen at the next step when new tests appear.

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

Refactor Phase: Improvement Without Risk

The green test is insurance for refactoring. The developer can rewrite the implementation, optimize performance, or improve readability, confident that the test will immediately detect any deviation from expected behavior. In Android mobile development, this phase is especially important for extracting common interfaces and reducing code duplication.

Benefits of TDD in Mobile Development

Applying TDD in mobile projects provides measurable benefits, confirmed by both academic research and the practice of leading development studios.

Reduced Defect Density

An IBM study (Bhat & Nagappan, 2006) across four industrial projects showed that teams using TDD produce 40% fewer defects compared to similar teams working with the traditional approach. For mobile development, where the cost of fixing a bug after a Google Play release is significantly higher than at the code writing stage, this metric is critical.

Code Documentation Through Tests

Tests written with TDD serve as living documentation of the API. A developer joining the project can read the tests and understand how each component should be used. This is especially valuable in high team turnover situations—a typical challenge for mobile studios.

Confident Refactoring

Code coverage exceeding 90% allows developers to refactor without fear of breaking something. Google, in its book “Software Engineering at Google” (2020), calls test coverage a key factor in keeping the codebase clean on projects with millions of lines of code.

Tools and Frameworks for TDD

The TDD ecosystem in mobile development includes tools for unit testing, mocking, and UI component verification—for both Android and iOS.

Choosing a Framework for Android

For Kotlin-based Android projects, the standard stack includes JUnit 5 + MockK. MockK is preferable to Mockito because it supports Kotlin first-class features—sealed classes, coroutines, and suspend functions—without additional setup.

Tools for iOS

In iOS development, TDD is implemented through XCTest—Apple’s built-in framework that provides assertions, test classes, and CI/CD integration via Xcode Server or GitHub Actions. For mocking on iOS, libraries like Cuckoo and OHHTTPStubs are used.

Code Examples with TDD in Kotlin

Let’s look at a real TDD scenario in Kotlin for Android—testing a user repository. First we write the test, then the implementation that passes the test.

Step 1: Test for 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) }
    }
}

Step 2: Minimal Implementation

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

Step 3: Test for Caching with Offline Mode

After passing the first test, we add a second one—checking behavior during a network error. Now the test determines that when the API fails, the repository should return data from the 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)
}

Common Mistakes When Implementing TDD

Transitioning to TDD comes with typical mistakes that can negate all the benefits of the methodology. Understanding these pitfalls helps teams adopt the practice more effectively.

Tests That Are Too Large

The first and most common anti-pattern is testing too much functionality in a single test. A test should verify exactly one assertion. If a test fails, the developer should know exactly what broke without additional debugging.

Ignoring the Red Phase

The second mistake is writing a test that initially passes. If the test was never red at least once, there is no confidence that it actually verifies anything. Rule: never trust a test you haven’t seen fail.

Skipping Refactoring

The third common mistake is stopping at the green phase. Refactoring is not optional but a mandatory step in the cycle. Without it, the codebase degrades, tests become brittle, and the benefits of TDD are lost.

• Testing implementation rather than behavior—tests become tied to details and break with every refactoring
• Missing edge case tests—empty lists, null values, boundary conditions remain uncovered
• Ignoring test speed—slow tests slow down the feedback loop and kill TDD discipline