16 · 🧪 API test चा प्रत्येक प्रकार — काउंटर test करण्याच्या नऊ पद्धती
📦 या ब्रँचमध्ये काय आहे
धडे 01–16 — पूर्ण कोर्स. api/ मध्ये काहीही नवीन नाही: हा धडा आधीपासून असलेले
कसे वापरायचे याबद्दल आहे.
- api/smoke_test.sh — smoke test: curl मधल्या नावे दिलेल्या 12 तपासण्या, प्रत्येक धड्यासाठी एक
- api/methods_demo.sh, api/auth_client.py, api/types_client.py — वेषांतर केलेल्या functional तपासण्या: प्रत्येक चालू काउंटरवर एक नियम assert करते
- 🗺️ संपूर्ण नकाशा: https://school-edh.pages.dev/api/lesson-diagrams.html#l16 — एका ओळीत एक असे काढलेले testing चे नऊ प्रकार, प्रत्येकासोबत तो या काउंटरवर कसा चालवायचा ते, आणि ते स्वीकारण्याचा क्रम
🧒 5 वर्षांच्या मुलाला समजावल्यासारखे
शाळा उघडण्याआधी तुम्ही प्रत्येक दिव्याचे बटण एकदा दाबून पाहता (smoke). मग तुम्ही नियमपुस्तिकेतला प्रत्येक नियम तपासता (functional), पूर्ण दिवसभर इमारतीतून फिरून पाहता (integration), आजची इमारत कालच्या फोटोशी जुळवता (regression), अपेक्षित गर्दीने सभागृह भरता (load), मग त्याच्या दहापट गर्दी आणून काय मोडते आणि ते पुन्हा सावरते का ते पाहता (stress), प्रत्येक दार चुकीच्या चावीने उघडून पाहता (security), विद्यार्थिनी वापरेल तसा सूचना फलक वापरता (UI), आणि शेवटी काउंटर दचकेपर्यंत त्याला निरर्थक गोष्टी भरवता (fuzz).
🗺️ आकृती
flowchart LR
S[smoke · every push] --> F[functional · every rule] --> I[integration · the stories] --> R[regression · diff the answers]
R --> L[load · before launch] --> SE[security · before public] --> FZ[fuzz · touch a parser] --> ST[stress · the failure mode] --> U[UI · a few golden paths]
❓ काय
| प्रकार | काय विचारतो | या काउंटरवर |
|---|---|---|
| Smoke | मुळात काही मोडते का? | bash api/smoke_test.sh — 12 तपासण्या, 30 सेकंद |
| Functional | spec जे सांगते ते हे करते का? | प्रत्येक नियमासाठी एक case: duplicate email → 409, key नाही → 401, एकच error shape |
| Integration | खऱ्या शेजाऱ्यांसह, एकामागून एक अनेक calls चालतात का? | enrol → read → update → delete → 404, webhook receiver चालू ठेवून |
| Regression | बदलामुळे आधी चालणारे मोडले का? | प्रत्येक उत्तराचा JSON नोंदवा; जुना build विरुद्ध नवा diff करा |
| Load | क्षमता किती आहे? | अपेक्षित traffic वर k6 / hey; p95, errors, 429s पाहा |
| Stress | ते कसे मोडते, आणि पुन्हा सावरते का? | 10× load; अपयश सभ्य 429s आहेत की crashes? |
| Security | प्रत्येक दार, प्रत्येक कुलूप | key नाही, चुकीची key, प्रत्येक field मध्ये injection, 1000 requests; logs तपासा |
| UI | सूचना फलकाद्वारे | UI शाळेचा फलक या API वर enrol form भरतो |
| Fuzz | त्याला निरर्थक गोष्टी भरवा | रिकामे, प्रचंड, चुकीचे types, unicode — कोणताही 500 किंवा अडकणे म्हणजे एक शोध |
🤔 का
प्रत्येक प्रकार अशा bugs चा वर्ग पकडतो जो इतर पकडू शकत नाहीत. Smoke "ते सुरूच होत नाही" पकडतो; functional "नियम चुकीचा आहे" पकडतो; integration "तुकड्यांचे एकमत नाही" पकडतो; regression "गेल्या मंगळवारी आपण ते मोडले" पकडतो; load आणि stress "ते कोसळते" पकडतात; security "कोणीही करू शकतो" पकडतो; fuzz "parser input वर विश्वास ठेवतो" पकडतो.
🔧 कसे (या repo मध्ये)
api/ मधली प्रत्येक script एक छोटी test आहे: smoke_test.sh प्रत्येक धड्यासाठी एक गोष्ट तपासतो,
methods_demo.sh तीन शब्द assert करतो, auth_client.py प्रत्येक 401 आणि 403 assert करतो,
types_client.py तारेवरचे सहा आकार assert करतो. CI/CD शाळा प्रत्येक push वर smoke test
चालवते; बाकीच्या सवयी काउंटर वाढेल तशा तुम्ही जोडता.
🧪 करून पाहा
python3 api/school_api.py &
bash api/smoke_test.sh # smoke
for i in $(seq 1 40); do curl -s -o /dev/null -w '%{http_code} ' http://127.0.0.1:8080/v1/health; done; echo # a tiny load test: watch the 429s begin
curl -s -X POST http://127.0.0.1:8080/v1/students -H 'X-API-Key: hall-pass-123' -H 'Content-Type: application/json' \
-d '{"name":"","class":"9Z","grade":"Z"}' # fuzz by hand: a 400 with problems, never a 500
✅ तपासा — तुम्हाला काय दिसायला हवे
Smoke test नावे दिलेले 12 blocks छापतो आणि एकही ❌ नाही. Load loop 200s छापतो, जे
bucket रिकामी झाल्यावर 429s मध्ये बदलतात (धडा 10). Fuzz request तीन problems सह
400 उत्तर देते — काउंटर सभ्यपणे दचकतो, आणि तेच योग्य उत्तर आहे.
🏁 तुम्ही आत्ताच काय सिद्ध केले
तुम्ही खऱ्या काउंटरवर testing च्या नऊपैकी तीन प्रकार चालवले, आणि उरलेल्या सहापैकी पुढे कोणते जोडायचे आणि का हे तुम्हाला माहीत आहे: प्रत्येक push वर smoke, प्रत्येक नियमासाठी functional, कथांसाठी integration, diff करून regression, launch आधी load, public होण्याआधी security, parser ला हात लावल्यावर fuzz, अपयशाची पद्धत समजण्यासाठी stress, काही सोनेरी मार्गांसाठी UI.
⚠️ नेहमीच्या चुका
- फक्त शेकडो end-to-end tests हेच एकमेव tests; roles ऐवजी CSS classes वर assert करणे.
- तुमच्या laptop वरून localhost वर load testing करून त्या आकड्याला "क्षमता" म्हणणे.
- 400 ला अपयश समजणारा fuzz run — problems सह 400 म्हणजे काउंटर नीट काम करत आहे.
- फक्त login endpoint साठी security tests; गळती object-level access मध्येच असते.
🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: pyramid म्हणजे अनेक functional, काही integration, थोडे end-to-end — आणि प्रत्येक deploy वर smoke. Regression वगळणाऱ्या टीम्स तोच bug दोनदा ship करतात; fuzz वगळणाऱ्या टीम्स एका emoji साठी 500 ship करतात.
🎓 कोर्स पूर्ण झाला
सोळा धडे: बारा धड्यांत बांधलेला एक काउंटर, आणि बाकी सगळ्याला जागा देणारे चार संपूर्ण नकाशे. अभ्यास आराखडा त्यांना खूण करतो; quiz मध्ये धडे 13–16 साठी भाग 3 आहे; School portal मध्ये प्रमाणपत्र आहे.