Claude ברירת מחדל שובר TDD, הנה למה
כשאתה מבקש מ-Claude Code "כתוב פונקציה שמחשבת הנחה", הוא כותב מימוש מיידית, ואז כותב tests שמאמתים בדיוק את מה שכתב. זה נקרא retroactive testing, והוא שווה בערך לכלום. Tests כאלו לעולם לא יכשלו, כי הם נכתבו על קוד שכבר קיים.
TDD אמיתי הפוך: כותבים tests שמגדירים מה הקוד צריך לעשות, לפני שנכתבה שורת מימוש אחת. הtest נכשל. אז כותבים מימוש שמעביר אותו. אז מנקים. זה מחזור Red-Green-Refactor.
כדי שClaude יבצע TDD אמיתי, צריך להיות מאוד מפורש: "כתוב tests בלבד. אסור לכתוב מימוש. הtest צריך להיכשל עכשיו." בלי ההוראה הזו, Claude ינסה "לעזור" ויוסיף מימוש, ויהרוס את הגישה כולה.
מחזור Red-Green-Refactor: שלושה שלבים, סדר קבוע
| שלב | מה עושים | מה Claude עושה | סימן הצלחה |
|---|---|---|---|
| Red | מתאר מה הפונקציה צריכה לעשות | כותב tests בלבד, אפס מימוש | pytest נכשל (ModuleNotFound / AssertionError) |
| Green | "עכשיו ממש את הקוד" | כותב מינימום מימוש לעבור tests | כל tests עוברים, אין קוד מיותר |
| Refactor | "נקה ושפר, אל תשבור tests" | משפר קריאות, מסיר כפילויות | tests עדיין עוברים, קוד נקי יותר |
כלל אחד שקהילת הפיתוח למדה ב-2025: "Asking an LLM to do TDD without structural enforcement is like asking water to flow uphill." המשמעות: אל תסמוך על Claude שיזכור TDD מעצמו, הטמע זאת ב-CLAUDE.md של הפרויקט.
דוגמה מלאה: מערכת הנחות לסטארטאפ ישראלי
נניח שאתה בונה מערכת תמחור לסטארטאפ SaaS בת"א. יש לך שלושה סוגי לקוחות: startup, enterprise, gov (ממשל). כל אחד מקבל הנחה שונה.
שלב Red, הפרומפט:
כתוב pytest tests בלבד (אסור לכתוב מימוש) לפונקציה:
calculate_discount(price: float, customer_type: str) -> float
הגדרות:
- startup: 15% הנחה
- enterprise: 5% הנחה
- gov: 0% הנחה (מחיר מלא)
- customer_type לא מוכר: raises ValueError("Unknown customer type")
- price שלילי: raises ValueError("Price must be positive")
- price=0: returns 0
כלול: test אחד לכל מקרה. אל תכתוב את הפונקציה עצמה.
הפעל pytest, אני מצפה שכולם ייכשלו.Claude מחזיר (tests בלבד):
import pytest
from pricing import calculate_discount
def test_startup_discount():
assert calculate_discount(1000.0, "startup") == 850.0
def test_enterprise_discount():
assert calculate_discount(1000.0, "enterprise") == 950.0
def test_gov_no_discount():
assert calculate_discount(1000.0, "gov") == 1000.0
def test_zero_price_returns_zero():
assert calculate_discount(0, "startup") == 0
def test_unknown_type_raises():
with pytest.raises(ValueError, match="Unknown customer type"):
calculate_discount(100.0, "vip")
def test_negative_price_raises():
with pytest.raises(ValueError, match="Price must be positive"):
calculate_discount(-50.0, "startup")הרץ pytest, תקבל ImportError כי pricing.py לא קיים. זה ה-Red הנכון.
שלב Green, פרומפט: "עכשיו כתוב את pricing.py כך שכל ה-tests יעברו. כתוב מינימום קוד."
שלב Refactor, פרומפט: "שפר: הוסף type hints, docstring, ושנה את DISCOUNTS ל-Enum. הבטח שהtests עדיין עוברים."
שגיאות נפוצות ואיך להימנע מהן
- שגיאה 1: מבקשים tests על קוד קיים. "כתוב tests לפונקציה שכבר כתבתי", זה לא TDD, זה אוטומציה של בדיקות. Tests כאלו לא חושפים bugs, הם מאשרים את מה שכבר קיים. פתרון: תמיד כתוב tests לפני שהפונקציה קיימת.
- שגיאה 2: Claude כותב מימוש "לעזור". גם אחרי שביקשת tests בלבד, Claude לפעמים יוסיף stub implementation. אם ראית קוד מחוץ לקובץ הtests, זו שגיאה. כתוב מפורש: "אסור לכתוב שום קוד מחוץ לקובץ test_X.py".
- שגיאה 3: כותבים את כל ה-tests בבת אחת. TDD הכי אפקטיבי עובד test אחד בכל פעם. כשכותבים הרבה tests, Claude ממציא behavior שלא הוגדר. כלל: Red → Green → Refactor על test בודד, ואז עוברים הלאה.
CLAUDE.md: אכיפת TDD בכל session
הבעיה של TDD בפרויקטים גדולים היא עקביות, כל session חדש עם Claude Code מתחיל מחדש. הפתרון הסטנדרטי ב-2025: הטמעת כללי TDD ב-CLAUDE.md של הפרויקט.
# CLAUDE.md
## Development Workflow
PRIORITY: Always follow TDD, Red-Green-Refactor.
### Rules:
1. When asked to implement a feature: write failing tests FIRST.
2. Never write implementation in the same step as tests.
3. After tests are confirmed failing, write minimal implementation.
4. After tests pass, refactor only if needed.
5. Run tests after every code change and report results.
### Test naming:
- test_[function]_[scenario]_[expected_outcome]
- Example: test_calculate_discount_startup_returns_15pctעם CLAUDE.md כזה, Claude יפעל לפי TDD בכל session, ללא צורך לחזור על ההוראות.
TDD בפרויקט אמיתי: מה הרווח?
נתוני קהילה מ-2025: כ-95% מה-tests שClaude מייצר בגישת TDD עוברים ללא שינוי. 85% מהם נחשבים relevant ואיכותיים. בהשוואה לכתיבת קוד ישירה ואז tests, TDD עם Claude מפחית bugs בסביבות 40% בשלב הראשוני.
עוד יתרון שקל להחמיץ: ה-tests שנוצרו ב-Red מהווים תיעוד חי של ה-API. כל מפתח שיצטרף לפרויקט יוכל להבין מה הקוד עושה מקריאת ה-tests בלבד, ללא תיעוד נפרד.