# Test-Driven Development: Write Better Code by Writing Tests First

## What is TDD Really?

[Test-Driven Development](https://www.geeksforgeeks.org/software-engineering/test-driven-development-tdd/) (TDD) is a coding approach where you **write tests before writing the actual code**. It sounds backward, but it transforms how you design and build software.

The cycle is simple:

1. **RED** - Write a failing test
    
2. **GREEN** - Write minimal code to pass
    
3. **REFACTOR** - Improve code without breaking tests
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1761089863280/32d3b705-b3a9-473c-9333-c3ba8d684ad5.png align="center")

## Why Bother with TDD?

### You'll Write Code That Actually Works

How many times have you "finished" coding, only to find hidden bugs later? TDD ensures every piece of functionality is verified the moment it's written.

### It Prevents Over-Engineering

When you write tests first, you only build what you actually need. No more "what if" features that complicate your code.

### Your Tests Actually Test Something

Ever written tests that always pass? With TDD, you see tests fail first, proving they can catch real problems.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1761089896482/2725598c-06fc-47d4-bcd0-ccf2ea809938.png align="center")

## Let's Build Twitter's Vowel Remover

Twitter famously removed vowels to fit messages in 140 characters. "Twitter" becomes "twttr". Let's build this using TDD.

### Step 1: RED - Write a Failing Test

```python
# test_twttr.py
from twttr import shorten

def test_remove_vowels_from_twitter():
    result = shorten("twitter")
    assert result == "twttr"
```

Run this test (`pytest test_`[`twttr.py`](http://twttr.py)). It fails because `shorten()` it doesn't exist yet.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1761089987022/de10a8f9-2af8-46cd-b573-8bf787b26462.png align="center")

**Why this matters**: The failure proves our test works and can detect problems.

### Step 2: GREEN - Write Minimal Code to Pass

```python
# twttr.py
def shorten(word):
    return "twttr"  # The simplest thing that could work(Cheating)
```

Run the test again. It passes!

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1761090063000/f2b2c27e-1acd-47c5-8572-3ac794de6ad0.png align="center")

**Why we "cheat"**: This keeps us focused on one requirement at a time.

### Step 3: Add Another Test - Back to RED

```python
def test_remove_vowels_from_hello():
    result = shorten("hello")
    assert result == "hll"
```

Run tests again. First test passes, second fails. Perfect progression.

### Step 4: Write Real Logic - GREEN

```python
def shorten(word):
    result = ""
    for char in word:
        if char.lower() not in "aeiou":
            result += char
    return result
```

Both tests pass! We now have working logic.

### Step 5: Add Edge Cases

```python
def test_empty_string():
    assert shorten("") == ""

def test_all_vowels():
    assert shorten("aeiou") == ""

def test_mixed_case():
    assert shorten("Hello World") == "Hll Wrld"
```

All tests pass with our current implementation.

### Step 6: REFACTOR

```python
def shorten(word):
    vowels = "aeiouAEIOU"
    return "".join(char for char in word if char not in vowels)
```

Run tests again - still green! We improved the code without breaking anything.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1761090112182/808125d6-158e-44a4-b184-7f4e17760530.png align="center")

## **Common TDD Objections (And Why They're Wrong)**

### "It Slows Me Down"

Short-term: yes. Long-term: you save hours of debugging and rewriting.

### "My Code Changes Too Much for Tests"

If your code changes frequently, tests are even more valuable. They catch breaks immediately.

### "I Don't Know What to Test"

Start with the happy path, then add edge cases:

* Normal input
    
* Empty input
    
* Boundary cases
    
* Error conditions
    

## When TDD Shines

* **New features**: Design through tests
    
* **Bug fixes**: Reproduce the bug with a test first
    
* **Legacy code**: Add tests before modifying
    
* **Learning**: Understand requirements before implementing
    

## Your TDD Cheat Sheet

1. **Think**: What's the smallest behaviour I need?
    
2. **Test**: Write a test for that behaviour
    
3. **Run**: Watch it fail (RED)
    
4. **Code**: Write minimal code to pass (GREEN)
    
5. **Clean**: Improve code without breaking tests (REFACTOR)
    
6. **Repeat**: Choose the next smallest behaviour
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1761090150501/a177f0ff-8f77-4f3a-a017-4492c040f05a.png align="center")

## Bottom Line

TDD isn't about religiously following rules. It's about building confidence in your code, one verified piece at a time.

The next time you start coding, try writing the test first. That red-to-green transition might just become your new addiction.