Tdd

TDD is an AI skill that implements the Test-Driven Development methodology by generating test cases before implementation code and guiding the red-green-refactor cycle. It covers test case generation from requirements, minimal implementation to pass tests, refactoring with test safety nets, and iterative development patterns that produce well-tested, cleanly designed code.

What Is This?

Overview

TDD provides automated support for the test-first development workflow. It generates executable test cases from feature descriptions or acceptance criteria, produces minimal implementation code that passes the generated tests, identifies refactoring opportunities once tests are green, tracks the red-green-refactor cycle to ensure each phase is completed, suggests the next test case based on uncovered scenarios, and maintains test suite quality by detecting redundant or overlapping tests.

Who Should Use This

This skill serves developers practicing test-driven development who want AI assistance in generating test cases, teams adopting TDD who need help establishing the workflow, engineers working on complex business logic that benefits from specification through tests, and projects where high test coverage is a requirement.

Why Use It?

Problems It Solves

Writing tests first is mentally challenging because it requires thinking about behavior before implementation. Developers often struggle to identify the right test cases to write next. The temptation to write more implementation than needed to pass the current test leads to untested code paths. Without discipline, the refactor phase is skipped, producing code that works but is poorly structured.

Core Highlights

The skill generates test cases that cover edge cases developers might miss. Implementation suggestions are intentionally minimal, following the TDD principle of writing just enough code to pass. Refactoring recommendations improve design while maintaining test coverage. The iterative cycle produces code with naturally high test coverage.

How to Use It?

Basic Usage

import pytest

def test_valid_password_accepted():
    assert validate_password("Secure1pass") is True

def test_short_password_rejected():
    assert validate_password("Short1") is False

def test_no_uppercase_rejected():
    assert validate_password("nouppercase1") is False

def test_no_digit_rejected():
    assert validate_password("NoDigitHere") is False

def validate_password(password):
    if len(password) < 8:
        return False
    if not any(c.isupper() for c in password):
        return False
    if not any(c.isdigit() for c in password):
        return False
    return True

Real-World Examples

import pytest
from decimal import Decimal

def test_percentage_discount_reduces_total():
    cart = ShoppingCart()
    cart.add_item("Widget", Decimal("100.00"), quantity=1)
    cart.apply_discount(DiscountCode("SAVE10", percent=10))
    assert cart.total == Decimal("90.00")

def test_discount_does_not_go_below_zero():
    cart = ShoppingCart()
    cart.add_item("Sample", Decimal("5.00"), quantity=1)
    cart.apply_discount(DiscountCode("MEGA", percent=100, max_discount=Decimal("5.00")))
    assert cart.total == Decimal("0.00")

def test_expired_discount_is_rejected():
    from datetime import date, timedelta
    expired = DiscountCode("OLD", percent=10, expires=date.today() - timedelta(days=1))
    cart = ShoppingCart()
    cart.add_item("Widget", Decimal("100.00"), quantity=1)
    with pytest.raises(ExpiredDiscountError):
        cart.apply_discount(expired)

def test_only_one_discount_per_cart():
    cart = ShoppingCart()
    cart.add_item("Widget", Decimal("100.00"), quantity=1)
    cart.apply_discount(DiscountCode("FIRST", percent=10))
    with pytest.raises(DiscountAlreadyAppliedError):
        cart.apply_discount(DiscountCode("SECOND", percent=5))

Advanced Tips

When a test is hard to write, it usually indicates the interface needs simplification. Treat test difficulty as design feedback. Write the assertion first, then work backward to set up the test state, as this clarifies what the test is actually verifying. Group related test cases into classes to share fixtures and make the test suite self-documenting.

When to Use It?

Use Cases

Use TDD when implementing business logic with complex rules and edge cases, when building library APIs where the interface design benefits from test-first thinking, when fixing bugs by first writing a test that reproduces the issue, or when working in a codebase that requires high test coverage.

Related Topics

Behavior-driven development, unit testing frameworks, refactoring techniques, clean code principles, and continuous integration all complement test-driven development.

Important Notes

Requirements

A testing framework configured for the project. Clear requirements or acceptance criteria to drive test generation. A development environment with fast test execution for rapid feedback.

Usage Recommendations

Do: write one test at a time and make it pass before writing the next. Keep the green phase minimal by writing only enough code to pass the current failing test. Refactor aggressively once all tests pass to improve code quality.

Don't: write multiple failing tests at once, as this complicates the feedback loop. Skip the refactor phase because the code already works. Test implementation details instead of observable behavior, as this creates brittle tests.

Limitations

TDD works best for logic-heavy code and is less effective for UI layout, framework configuration, and infrastructure setup. The practice requires discipline to maintain consistently, and deadline pressure often leads teams to skip the test-first step. Generated test cases may not capture all domain-specific edge cases without expert guidance.