أوامر مراجعة الكود (الأمن / الأداء / القابلية للقراءة)
Tests من الـ Spec
لما بتراجع 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.pyand 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 سطر واحد. :::
سجّل الدخول للتقييم