Claude Architect · पाठ

टेस्ट जनरेशन और मानक

जनरेट किए गए tests को बेहतर बनाने के लिए fixtures और मानकों का दस्तावेज़ीकरण कीजिए।

पाठ 4, कुल 4 में से13 चरण

टेस्ट जनरेशन और मानक, CoddyKit पर Claude Architect का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Claude Architect सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

बनाए गए परीक्षण क्यों भटक जाते हैं

क्लॉड को बिना किसी मार्गदर्शन के "इस मॉड्यूल के लिए परीक्षण लिखो" कहें, तो आपको ऐसे परीक्षण मिलेंगे जो चलते तो हैं, लेकिन आपकी टीम की शैली से मेल नहीं खाते: गलत फ़्रेमवर्क सहायक, गढ़े हुए फिक्स्चर, और ऐसे अभिकथन जो कॉन्ट्रैक्ट के बजाय कार्यान्वयन की नकल करते हैं।

समाधान कोई बेहतर एक-बार का प्रॉम्प्ट नहीं है। समाधान हैं स्थायी, साझा मानक जिन्हें मॉडल हर बार पढ़ता है। यह पाठ बताता है कि फिक्स्चर और परंपराओं का दस्तावेज़ीकरण कैसे करें, ताकि बनाए गए परीक्षण संवादात्मक सत्रों और CI दोनों में स्वाभाविक, नियतात्मक और समीक्षा योग्य हों।

परियोजना-दायरे वाली CLAUDE.md में मानक रखें

परीक्षण की परंपराएँ परियोजना-स्तरीय कॉन्फ़िगरेशन में होनी चाहिए, ताकि हर योगदानकर्ता और हर CI रनर उन्हें देख सके। उन्हें ./CLAUDE.md या .claude/CLAUDE.md में रखें, जिसे VCS के माध्यम से साझा किया जाता है।

नहीं, उपयोगकर्ता-स्तरीय ~/.claude/CLAUDE.md पर निर्भर न रहें: वह व्यक्तिगत है और संस्करण नियंत्रण के माध्यम से साझा नहीं होती, इसलिए नए सहकर्मियों और आपके कार्यप्रवाह के पास वह नहीं होगी। परीक्षण निर्माण जिन बातों पर निर्भर है, वे सब परियोजना-दायरे में होनी चाहिए।

# ./CLAUDE.md  (committed -> every dev + CI sees it)

## Testing standards
- Framework: pytest; one test file per module as tests/test_<module>.py
- Name tests test_<behavior>_<condition>_<expected>
- Assert on the public contract, never on private internals
- No network or real time in unit tests; use the provided fixtures

@path आयातों से मॉड्यूलर बनाएँ

एकल, विशाल CLAUDE.md पढ़ने में कठिन हो जाती है और संदर्भ खपा देती है। विस्तृत परीक्षण मार्गदर्शिका को अपनी फ़ाइल में रखें और @path सिंटैक्स से आयात करें। इससे मूल फ़ाइल संक्षिप्त रहती है और मानक फिर भी लोड होता है।

आयात की गई फ़ाइल केवल markdown होती है और बाकी सबकी तरह संस्करण-नियंत्रित रहती है, इसलिए मानक का पुनः उपयोग करना और अलग से उसकी समीक्षा करना आसान होता है।

# ./CLAUDE.md
@./standards/testing-style.md
@./standards/fixtures.md

# Each imported file documents one slice of the standard,
# keeping the root CLAUDE.md short and scannable.

ज़रूरत पड़ने पर ही परीक्षण नियम लोड करें

हर समय सक्रिय आयात से भी बेहतर तरीका है: परीक्षण की परंपराएँ .claude/rules/ की ऐसी फ़ाइल में रखें जिसमें YAML frontmatter paths हो। नियम केवल मेल खाने वाली फ़ाइलों को संपादित करते समय लोड होता है, इसलिए हर चरण में सब कुछ भेजने वाली विशाल CLAUDE.md की तुलना में संदर्भ और टोकन बचते हैं।

किसी नियम का दायरा अपनी परीक्षण निर्देशिका तक रखें। तब वह ठीक उसी समय सक्रिय होगा जब क्लॉड परीक्षण बना या संपादित कर रहा होगा और बाकी समय बाधा नहीं बनेगा।

# .claude/rules/testing.md
---
paths:
  - "tests/**"
  - "**/*.test.ts"
---
# Loaded only when a matching test file is in play
- Arrange-Act-Assert, one logical assertion per test
- Reuse fixtures from conftest.py; never hand-roll a DB
- Cover the happy path, one edge case, and one failure case

फिक्स्चर को विश्वसनीय स्रोत के रूप में दस्तावेज़ित करें

खराब बनाए गए परीक्षणों का सबसे बड़ा एकल कारण हैं गढ़े हुए फिक्स्चर: मॉडल आपके फिक्स्चर का उपयोग करने के बजाय उपयोगकर्ता ऑब्जेक्ट या डेटाबेस स्टब गढ़ देता है। वास्तविक फिक्स्चर का दस्तावेज़ीकरण करें, ताकि क्लॉड उनका फिर से उपयोग करे।

बताएँ कि प्रत्येक फिक्स्चर क्या देता है, उसका आकार क्या है और उसका उपयोग कब करना है। इसे टूल के विवरण की तरह समझें: उद्देश्य, लौटाया गया मान, इनपुट प्रारूप और लागू होने की सीमाएँ ही सही चयन करवाती हैं।

# ./standards/fixtures.md  (imported into CLAUDE.md)

## Available pytest fixtures (use these, do NOT invent)
- `db`        -> in-memory SQLite session, auto-rolled-back per test
- `client`    -> FastAPI TestClient with auth middleware disabled
- `user`      -> a persisted User(id=1, role="member"); returns the ORM obj
- `frozen_now`-> pins datetime.utcnow() to 2026-01-01T00:00:00Z

# Need a different state? Parametrize an existing fixture; don't create a new DB.

कुछ उदाहरण अस्पष्ट नियमों से बेहतर हैं

केवल गद्य अस्पष्टता छोड़ देता है। किसी मानक परीक्षण के 2 से 4 लक्षित उदाहरण जोड़ें और मॉडल पैटर्न का सामान्यीकरण करेगा; वह केवल उसकी नकल नहीं करेगा। few-shot उदाहरण संगति, सीमांत मामलों और परिणाम के प्रारूप के लिए सबसे प्रभावी साधन हैं।

अपने वास्तविक फिक्स्चर का उपयोग करने वाला एक पूरा, स्वाभाविक परीक्षण दिखाएँ। नए परीक्षण उसकी संरचना, नामकरण और अभिकथन शैली की नकल करेंगे।

# ./standards/testing-style.md  (a canonical example to generalize from)

def test_transfer_rejects_when_balance_too_low(db, user):
    account = make_account(db, owner=user, balance=50)
    with pytest.raises(InsufficientFunds):
        transfer(db, account, amount=100)
    assert account.balance == 50          # state unchanged on failure
# ^ Note: AAA layout, real `db`/`user` fixtures, asserts the contract.

अस्पष्ट इच्छाओं के बजाय स्पष्ट मानदंड लिखें

"अच्छे परीक्षण लिखें" एक अस्पष्ट इच्छा है। स्पष्ट मानदंड विश्वसनीय परिणाम देते हैं। "पूरी तरह जाँचें" की तुलना "सफल मार्ग, एक सीमा मान और एक त्रुटि मार्ग शामिल करें; निजी विधियों का सीधे परीक्षण कभी न करें" से करें।

ठोस और जाँचे जा सकने वाले नियम उस अनुमान को हटा देते हैं जिसके कारण अलग-अलग फ़ाइलों और योगदानकर्ताओं के बीच बनाए गए परीक्षण असंगत हो जाते हैं।

# In CLAUDE.md or the generation prompt -- explicit and checkable:
- Each public function gets: 1 happy-path, 1 edge/boundary, 1 failure test
- A test may fail for exactly ONE reason; split otherwise
- Mock ONLY at process boundaries (network, clock, filesystem)
- Forbidden: sleeping on real time, hitting a live service, asserting log text

निर्माण को कौशल के रूप में समाहित करें

.claude/skills/ के कौशल से कार्यप्रवाह को दोहराने योग्य बनाएँ (परियोजना-दायरा VCS के माध्यम से साझा होता है; उपयोगकर्ता-दायरा व्यक्तिगत होता है)। यह कौशल आपके मानक को एक साथ रख सकता है, टूल सीमित कर सकता है और परिणाम को पृथक कर सकता है।

विस्तृत निर्माण परिणाम को पृथक करने के लिए context: fork, उसे किन चीज़ों को छूने की अनुमति है यह सीमित करने के लिए allowed-tools, और बुलाने वाले को दिशा देने के लिए argument-hint का उपयोग करें। अब "मानक के अनुसार परीक्षण बनाएँ" दोबारा लिखे गए अनुच्छेद के बजाय एक पुनः उपयोग योग्य कमांड है।

# .claude/skills/gen-tests/SKILL.md
---
name: gen-tests
description: Generate tests for a module using project fixtures + style
context: fork
allowed-tools: [Read, Glob, Grep, Write]
argument-hint: <path/to/module.py>
---
Follow @./standards/testing-style.md and @./standards/fixtures.md.
Find siblings with Glob **/*test*, reuse existing fixtures, then Write the test file.

निर्माण से पहले पैटर्न खोजें

बिना आधार के निर्माण न करें। पहले क्लॉड से क्रमिक जाँच वाले पैटर्न का पालन करवाएँ: मौजूदा परीक्षण फ़ाइलों के लिए Glob, उनमें से कुछ के लिए Read, किसी फिक्स्चर के उपयोग का तरीका जानने के लिए Grep, फिर पहले से मौजूद शैली से मेल खाता नया परीक्षण लिखें।

वास्तविक कोडबेस में निर्माण को आधार देना शैली-मार्गदर्शिका दोहराने से बेहतर है, क्योंकि मॉडल अनुमान लगाने के बजाय जीवित और काम कर रही परंपराओं की नकल करता है।

# Glob to discover the established test layout
claude -p "Glob tests/**/*.py, Read two existing tests, \
Grep for usages of the `client` fixture, then write tests/test_orders.py \
following the same fixtures and naming. Do not invent new fixtures."

CI में बिना स्क्रीन निर्माण करें, नई समीक्षा करें

कार्यप्रवाह में, -p से बिना स्क्रीन परीक्षण बनाएँ (यह आवश्यक है क्योंकि कोई मनुष्य उपस्थित नहीं होता) और --output-format json का उपयोग करें, ताकि बाद का चरण परिणाम को पार्स कर सके। फिर बनाए गए परीक्षणों की अलग, पृथक सत्र में समीक्षा करें।

नए इंस्टेंस की समीक्षा उसी सत्र की आत्म-समीक्षा से बेहतर होती है: लेखक अपने तर्क से जुड़ा रहता है और अपने परीक्षणों को चुनौती नहीं देगा। स्वच्छ समीक्षक उन चक्रीय अभिकथनों और छूटे हुए विफलता मामलों को पकड़ लेता है जिन्हें निर्माता ने अनदेखा कर दिया।

# 1) Generate (headless, parseable)
claude -p "$(cat .ci/gen-tests-prompt.md)" --output-format json > gen.json

# 2) Review in a FRESH session, not the generation context
claude -p "Review the new tests in gen.json against ./standards/testing-style.md. \
Flag tautological asserts and any missing failure-path test." \
  --output-format json > review.json

संरचना की पुष्टि करें, फिर प्रतिक्रिया के साथ दोबारा प्रयास करें

जब आप संरचित परिणाम (tool_use + JSON Schema) के रूप में परीक्षण माँगें, तो परिणाम की पुष्टि करें। यदि वह गलत प्रारूप का हो, तो प्रतिक्रिया के साथ दोबारा प्रयास करें: मूल अनुरोध, गलत परिणाम और पुष्टि की सटीक त्रुटि फिर भेजें। इससे प्रारूप और संरचना की गलतियाँ विश्वसनीय रूप से ठीक होती हैं।

तथ्य-पत्रक से दो सावधानियाँ: जब आवश्यक जानकारी स्रोत में ही अनुपस्थित हो, तो दोबारा प्रयास मदद नहीं करता; और स्कीमा फ़ील्ड को केवल तभी अनिवार्य चिह्नित करें जब वह हमेशा मौजूद हो, वरना मॉडल उसका मान गढ़ देगा।

# Schema for emitted test cases -- 'edge_case' is optional, so NOT required
{
  "type": "object",
  "properties": {
    "test_name":   {"type": "string"},
    "fixtures":    {"type": "array", "items": {"type": "string"}},
    "assertion":   {"type": "string"},
    "edge_case":   {"type": "string"}
  },
  "required": ["test_name", "fixtures", "assertion"]
}
# On a validation failure: resend original + bad output + the exact error.

त्वरित जाँच

इस पाठ को मानकों से जुड़े एक वास्तविक निर्णय पर लागू करें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन: परीक्षण निर्माण और मानक

मुख्य निष्कर्ष:

परीक्षण मानकों को परियोजना-दायरे में रखें (./CLAUDE.md, paths वाली .claude/rules/), VCS के माध्यम से साझा करें; CI में व्यक्तिगत ~/.claude/CLAUDE.md पर कभी निर्भर न रहें।
@path आयातों से मॉड्यूलर बनाएँ; frontmatter paths वाले नियम केवल मेल खाने वाली फ़ाइलों को संपादित करते समय लोड होते हैं और संदर्भ बचाते हैं।
फिक्स्चर का दस्तावेज़ीकरण विश्वसनीय स्रोत के रूप में करें (उद्देश्य, आकार, उपयोग का समय), ताकि मॉडल स्टब गढ़ने के बजाय उनका फिर से उपयोग करे।
Few-shot (2-4 मानक उदाहरण) और स्पष्ट मानदंड अस्पष्ट निर्देशों से बेहतर हैं; मॉडल पैटर्न का सामान्यीकरण करता है।
इसे .claude/skills/ कौशल में समाहित करें; लिखने से पहले क्लॉड से मौजूदा परीक्षणों की जाँच करवाएँ (Glob/Read/Grep)।
CI में -p --output-format json के साथ बिना स्क्रीन निर्माण करें, फिर नए, पृथक सत्र में समीक्षा करें।
संरचित परिणाम की पुष्टि करें; प्रतिक्रिया के साथ दोबारा प्रयास प्रारूप की त्रुटियाँ ठीक करता है, पर अनुपस्थित जानकारी नहीं, और स्कीमा फ़ील्ड को केवल तभी अनिवार्य करें जब वह हमेशा मौजूद हो।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Python सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 26
पाठ: 104

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “टेस्ट जनरेशन और मानक” पाठ निःशुल्क है?

हाँ — Claude Architect अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “टेस्ट जनरेशन और मानक” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“टेस्ट जनरेशन और मानक” में मैं क्या सीखूँगा?

जनरेट किए गए tests को बेहतर बनाने के लिए fixtures और मानकों का दस्तावेज़ीकरण कीजिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Claude Architect का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Claude Architect शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Claude Architect शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“टेस्ट जनरेशन और मानक” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Claude Architect पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Claude Architect पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

← Claude Architect पर वापस जाएँ