أوامر مراجعة الكود (الأمن / الأداء / القابلية للقراءة)

Tests من الـ Spec

5 دقيقة للقراءة

لما بتراجع PR ناقصه tests، عندك اختيارين. ترجع للكاتب وتستنى. أو تكتب الـ tests بنفسك في الدقيقة الجاية وتفك الـ review. التاني عادة أسرع وأصح للفريق.

Prompt الـ spec-to-tests هو الفعّال في ده. ادّي للموديل signature الـ function، مثال input/output، وlist صريحة بالـ cases تغطّيها. بيرجع ملف tests تلصقه.

Write pytest tests for a function split_invoice_lines(text: str) -> list[dict] that parses lines like: "3 x Latte @ 65" -> {"qty": 3, "item": "Latte", "unit_price": 65}

Cover:

  • Single line happy path.
  • Multiple lines (newline-separated).
  • Whitespace tolerance (extra spaces).
  • Decimal price ("@ 65.50").
  • Invalid line (no "x" or no "@") raises ValueError.
  • Empty string returns [].

Output ONLY the test file, with imports.

Claude Sonnet 4.5 رجّع ملف طويل فيه الـ function والـ tests (الرد اتقطع عند الحد). الجزء المتعلق بالـ tests شكله:

def test_single_line_happy_path():
    """Test parsing a single valid invoice line."""
    text = "3 x Latte @ 65"
    result = split_invoice_lines(text)

    assert len(result) == 1
    assert result[0] == {"qty": 3, "item": "Latte", "unit_price": 65.0}


def test_multiple_lines():
    """Test parsing multiple newline-separated invoice lines."""
    text = """3 x Latte @ 65
2 x Espresso @ 50
1 x Cappuccino @ 70"""

    result = split_invoice_lines(text)

    assert len(result) == 3
    assert result[0] == {"qty": 3, "item": "Latte", "unit_price": 65.0}
    assert result[1] == {"qty": 2, "item": "Espresso", "unit_price": 50.0}

Captured from Claude Sonnet 4.5 (claude-sonnet-4-5) on 2026-04-27. Re-runs may differ slightly.

ملاحظتين مهمتين:

حاجة 1: الموديل ضاف implementation للـ function مع الـ tests. ده عشان الـ prompt ما قالش "tests بس — افترض الـ function موجودة." من غير الـ constraint ده، الموديل بنية إنه يساعد بيكتب الـ function عشان الـ tests يكون عندها حاجة تستوردها. ده ما يضرش لو بتـprototype. بس ضوضاء لو بتراجع PR فيه الـ implementation بالفعل. ضيف الـ constraint:

Assume the function is already implemented in app/invoices.py and import it. Output the test file only.

حاجة 2: كل test بيعمل حاجة واحدة. test_single_line_happy_path ما بيتأكدش كمان من whitespace tolerance. test_multiple_lines ما بيتأكدش كمان من decimal prices. الـ cases في الـ prompt بقت أسامي الـ tests — case واحد لكل test. ده الانضباط اللي تتمنّاه من زميل بحرص.

إزاي الـ spec بتتحوّل لـ suite بـ test لكل خاصية:

عشان prompts spec-to-tests تبقى أصرم لاستخدام الـ code review، ضيف الـ constraints دي:

Constraintبيعمل إيه
Assume the function is already implementedبيمنع الموديل من إعادة كتابة الـ function
One assert per propertyبيتجنب "passes for the wrong reason"
Each test name describes the property testedالـ tests بتبقى documentation
Use parametrize where 3+ cases share structureبيقلّل line count لـ cases متشابهة

خطوة مفيدة تالية على نفس الـ prompt: اطلب ملف tests تاني بيستهدف بس boundary cases اللي الكاتب على الأرجح نسيها. Input فاضي، حرف واحد، input بأقصى طول، unicode. ذاكرة الموديل عن edge cases ممتازة لأنه شاف آلاف bug reports مشابهة في التدريب. استخدم ده.

تقدر تضمّ prompt الـ spec-to-tests مع prompt المراجعة من الدرس 1: "Review this PR. If tests are missing, generate them in pytest format." دلوقتي pass المراجعة بيطلّع الـ feedback والـ tests في round-trip واحد.

التالي: تخلّي الموديل يلتزم بـ verdict سطر واحد. :::

اختبار

الوحدة 4: Prompts المراجعة

خذ الاختبار
هل كان هذا الدرس مفيدًا؟

سجّل الدخول للتقييم

نشرة أسبوعية مجانية

ابقَ على مسار النيرد

بريد واحد أسبوعياً — دورات، مقالات معمّقة، أدوات، وتجارب ذكاء اصطناعي.

بدون إزعاج. إلغاء الاشتراك في أي وقت.