आपको बिना किसी documentation के एक REST endpoint थमा दिया गया है। आप क्या टेस्ट करते हैं?

contract से शुरू कीजिए: status codes, response schema, content types, और कौन से field जरूरी हैं कौन से नहीं। फिर हर input जांचिए (गायब, गलत type, रेंज से बाहर, बहुत बड़ा), authentication और authorization टेस्ट कीजिए जिसमें किसी दूसरे user के resource तक पहुंच भी शामिल हो, error responses की एकरूपता देखिए, दोबारा भेजने पर idempotency, pagination और sorting, rate limiting, और यह कि कोई dependency फेल या timeout हो जाए तो क्या होता है।

पहले मैं contract का नक्शा बनाता हूं, क्योंकि बिना docs के मुझे आकार जानना होगा तभी उस पर राय बना सकूंगा। सीधा call, फिर status code, headers, response body, और यह देखना कि fields के नाम और types एक जैसे हैं या नहीं। फिर मैं एक एक करके inputs पर हमला करता हूं: हर जरूरी field हटाकर देखो, जहां संख्या चाहिए वहां string भेजो, ऋणात्मक भेजो, जो लंबाई ठीक लगे उससे आगे की value भेजो, ऐसे अतिरिक्त fields भेजो जो मांगे ही नहीं गए और देखो कि वह उन्हें ठुकराता है या चुपचाप नजरअंदाज करता है। फिर वह हिस्सा जिसकी मुझे सबसे ज्यादा परवाह है, यानी authorization, जो authentication से अलग चीज है। logged in होना अनुमति नहीं है। तो मैं एक user का वैध token लेता हूं और ID से किसी दूसरे user का resource मांगता हूं, क्योंकि यह वर्ग वाला bug आम भी है और सच में गंभीर भी। उसके बाद: दोबारा भेजा गया POST दो records बनाता है क्या, pagination page शून्य पर और अंत से आगे कैसा बर्ताव करता है, error bodies का आकार एक जैसा है क्या, rate limiting है क्या, और नीचे की कोई service धीमी हो तो क्या होता है। मैं उस पर एक proxy लगाकर responses से छेड़छाड़ भी करूंगा ताकि देखूं कि वह संभलकर गिरता है या 500 फेंक देता है।