Test-Driven Development (TDD) کیا ہے؟

Question

Accepted Answer

**Test-Driven Development (TDD)** ایک طریقہ کار ہے جہاں آپ **کوڈ لکھنے سے پہلے ٹیسٹ لکھتے ہیں** — ایک مختصر، بار بار دہرایا جانے والا سائیکل اپناتے ہوئے: ایک ناکام ٹیسٹ لکھیں، اسے پاس کرنے کے لیے کوڈ لکھیں، پھر refactor کریں۔ یہ ٹیسٹس کے ذریعے ڈیزائن کو چلاتا ہے اور کوڈ کو testable اور اچھی طرح سے tested ہونا یقینی بناتا ہے۔

## TDD سائیکل: Red, Green, Refactor

```text
1. RED → write a FAILING test for the behavior you want (it fails — the code doesn't exist yet)
2. GREEN → write the MINIMUM code to make the test PASS (just enough, don't over-build)
3. REFACTOR → improve/clean up the code (and tests) while keeping tests GREEN
→ Repeat this short cycle for each small piece of behavior.
```

```text
Write test (RED) → write code (GREEN) → clean up (REFACTOR) → repeat
```

## مثال کے طور پر بہاؤ

```js
// 1. RED — write the test first (fails: add doesn't exist / is wrong)
test('add(2,3) === 5', () => expect(add(2, 3)).toBe(5));

// 2. GREEN — write minimal code to pass
function add(a, b) { return a + b; }

// 3. REFACTOR — improve if needed (test still passes); then write the next test
```

## فوائل اور تحفظات

```text
✓ Ensures code is TESTABLE (you design for testing) and TESTED (tests exist by definition)
✓ Drives DESIGN — thinking about behavior/interface first → cleaner, focused code
✓ Fast FEEDBACK; confidence to refactor; avoids over-engineering (write only what's needed)
✓ Good test coverage as a natural result
⚠️ A discipline/skill that takes practice; not always applied dogmatically (use judgment)
```

## اہمیت

Test-Driven Development کو سمجھنا قیمتی ہے کیونکہ یہ ایک **بااثر، بڑے پیمانے پر بحث کیا جانے والا طریقہ کار** ہے جو بہت سارے developers کے testing اور design کے نقطہ نظر کو متاثر کرتا ہے، تو یہ پروفیشنل ڈیولپمنٹ کے لیے اہم علم ہے۔

TDD کا بنیادی خیال — **کوڈ سے پہلے ٹیسٹ لکھنا**، **Red-Green-Refactor سائیکل** کی پیروی کرتے ہوئے (ایک ناکام ٹیسٹ لکھیں، اسے پاس کرنے کے لیے کم سے کم کوڈ لکھیں، پھر ٹیسٹ کو سبز رکھتے ہوئے refactor کریں) — ایک منفرد نقطہ نظر ہے جو معمول کی ترتیب کو الٹ دیتا ہے۔

سائیکل کو سمجھنا بنیادی عملی علم ہے۔

**فوائل** کو سمجھنا وضاحت کرتا ہے کہ TDD کی قدر کیوں کی جاتی ہے: یہ یقینی بناتا ہے کہ کوڈ **testable** ہے (شروع سے ہی testing کے لیے ڈیزائن کر کے) اور **tested** ہے (تعریف کے لحاظ سے ٹیسٹ موجود ہیں)، **ڈیزائن کو چلاتا ہے** (سلوک اور interface کے بارے میں پہلے سوچنا صاف، زیادہ focused کوڈ کی طرف لے جاتا ہے)، تیز رفتار رائے اور refactor کرنے کا اعتماد فراہم کرتا ہے، over-engineering سے بچاتا ہے (صرف وہی لکھنا جو ٹیسٹ پاس کرنے کے لیے درکار ہے)، اور قدرتی طور پر اچھی ٹیسٹ coverage تیار کرتا ہے۔

یہ فوائل TDD کو ایک testing اور design کے طریقہ کار دونوں کے طور پر بااثر بناتے ہیں۔

**تحفظات** کو سمجھنا — کہ TDD ایک نظم و ضبط ہے جس میں مشق کی ضرورت ہے، اور یہ کہ اسے ہمیشہ dogmatically لاگو نہیں کیا جاتا (developers قضاوت استعمال کرتے ہیں کہ یہ کب فٹ بیٹھتا ہے) — ایک متوازن، حقیقی نقطہ نظر کو ظاہر کرتا ہے۔

جو developers ہمیشہ TDD کا مشق نہیں کرتے وہ بھی اسے سمجھنے سے فائدہ اٹھاتے ہیں، کیونکہ یہ testing اور design کے بارے میں سوچ کو متاثر کرتا ہے اور پروفیشنل ڈیولپمنٹ میں ایک عام موضوع ہے۔

کیونکہ TDD ایک بااثر، بڑے پیمانے پر معروف طریقہ کار ہے جو testing اور design کے طریقوں کو متاثر کرتا ہے (testability، design، اور coverage میں حقیقی فوائل کے ساتھ) اور ایک عام پروفیشنل اور interview موضوع ہے، اور کیونکہ سائیکل، فوائل، اور تحفظات کو سمجھنا testing کے پختگی کو ظاہر کرتا ہے، Test-Driven Development کو سمجھنا قیمتی، متعلقہ علم ہے — ایک اہم testing طریقہ کار اور فلسفہ جو پروفیشنل ڈیولپمنٹ کے لیے سمجھنے کے قابل ہے، جو quality-focused developers کے لیے بااثر ہے کہ وہ software بنانے کا طریقہ بھی استعمال کرتے ہیں۔