Learn-json-web-tokens: परीक्षण API जो JWTs का उपयोग करता है

खैर, मेरे पास कुछ सुझाव हैं जो काम कर सकते हैं:

1. अपने सिस्टम में एक _test_ क्लाइंट सेटअप करें और परीक्षणों में एक टोकन को हार्डकोड करें। प्रमाणीकरण चालू रखें।
2. सुनिश्चित करें कि परीक्षण चलाते समय प्रमाणीकरण बंद है। मुझे लगता है कि ऐसा करने के विभिन्न तरीके हैं। उदाहरण के लिए हापी में आप डिफ़ॉल्ट प्रमाणीकरण योजना को छोड़ सकते हैं, और केवल एक सेट कर सकते हैं, जब सर्वर वास्तव में चलता है (लेकिन परीक्षण चलाते समय नहीं)।
3. स्टैक का मज़ाक उड़ाएं, इसलिए आप सिस्टम के माध्यम से अनुरोध किए बिना केवल नियंत्रक तर्क का परीक्षण कर रहे हैं। हालांकि कुछ ढांचे में यह संभव नहीं हो सकता है।

मैं कुछ प्रणालियों पर काम कर रहा हूं, जहां हमने (1) चुना है। परीक्षण तब एकीकरण परीक्षणों की तरह थोड़ा अधिक दिखता है, न कि इकाई परीक्षण, क्योंकि वे ढेर के माध्यम से चलते हैं। दूसरी ओर, परीक्षण और उत्पादन वातावरण के बीच कोई असमानता नहीं है।

यदि आप कोड में परिवेश का निर्धारण करना चाहते हैं, तो परीक्षण चलाते समय आप NODE_ENV=test सेट कर सकते हैं (fx. -e पैरामीटर लैब में )। हालांकि, आपको पता होना चाहिए कि परीक्षण और उत्पादन वातावरण बहुत अधिक भिन्न नहीं है, अन्यथा आप वास्तव में उत्पादन वातावरण का परीक्षण नहीं कर रहे हैं।

@ rhewitt22 हम @walling . द्वारा वर्णित दृष्टिकोण को पसंद करते हैं
(जहां परीक्षण अधिक बारीकी से "इकाई" परीक्षणों के बजाय "एकीकरण" जैसा दिखता है)
_ठीक_उस कारण से। आप जो कुछ भी मजाक करते हैं वह "_fake_" है और इस प्रकार आपको पता नहीं चलेगा कि कब कुछ "_real_" काम करता है या नहीं (_so बग अधिक संभावना है_)।

हमें (_large_) प्रोजेक्ट विरासत में मिले हैं, जहां लोग _भूल जाते हैं, जब वे तरीके बदलते हैं तो मॉक अपडेट करना भूल जाते हैं और परिणामस्वरूप परीक्षण _वास्तविकता_ को प्रतिबिंबित नहीं करते हैं; डिबग करने के लिए दुःस्वप्न _!

हमेशा अपने आप से पूछें: "_( क्यों ) क्या हमें इसका मज़ाक उड़ाने की ज़रूरत है?_"

यदि आप किसी चीज़ का मज़ाक उड़ा रहे हैं क्योंकि यह आपके नियंत्रण से बाहर है जैसे कि कोई तृतीय पक्ष सेवा या नेटवर्क उपकरण,
यह समझ में आता है। लेकिन अगर आप अपने _खुद के ढेर_ का मजाक उड़ा रहे हैं तो आपको लगता है कि आप चीजों को अधिक जटिल कर सकते हैं ...

आपके _question_ में सुराग " _API _" शब्द में है, यह इंगित करता है कि आप "इकाई" का परीक्षण नहीं कर रहे हैं, बल्कि एक (API) "_ समापन बिंदु _" का परीक्षण कर रहे हैं।

एंडपॉइंट मारो और अगर आपको 401 मिलता है तो आप जानते हैं कि आपको _प्रमाणीकरण_ करने की आवश्यकता है! (_अच्छी खबर! आपका ऐप उम्मीद के मुताबिक काम करता है!_)

यहां एक परीक्षण का _कार्य उदाहरण _ है जो _ है जो आपको चाहिए _:
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

तब मैं पढ़ने की सलाह दूंगा:

• कब मॉक करें: https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• मोक्स स्टब्स नहीं हैं: http://martinfowler.com/articles/mocksArentStubs.html
• माइक्रोसर्विसेज परीक्षण: http://martinfowler.com/articles/microservice-testing/
• मुझे कब उपहास करना चाहिए? http://stackoverflow.com/questions/38181/जब-चाहिए-आई-मॉक

टीएल; डॉ

यदि आपका _अपना_कोड बहुत जटिल है और आपको इसका उपहास करने की आवश्यकता महसूस होती है, तो _पहले अपने कोड को सरल बनाएं _!!

साथ ही, हमने अपना hapi-auth-jwt2 प्लगइन लिखा है ताकि दूसरे हमारे परीक्षण पर भरोसा कर सकें। और एक _लीनियर स्केलेबल_ रेडिस-समर्थित उदाहरण जारी किया: https://github.com/dwyl/hapi-auth-jwt2-example ताकि लोग कॉपी-पेस्ट (_tested_) कोड कर सकें! :आँख मारना:

_हम_ केवल तब उपहास करते हैं जब हमारे परीक्षण "_फील बहुत धीमी _" अन्यथा हम _हमेशा_ प्रत्येक परीक्षा पास पर _संभव_ के रूप में अधिक से अधिक स्टैक का अभ्यास करते हैं (जबकि निर्भरता को केवल _आवश्यक_ तक सीमित करते हुए)।

यदि आपके ऐप की कार्यक्षमता के किसी तत्व को प्रमाणीकरण की आवश्यकता है, तो आप इसे _opportunity_ से _exercise_ के रूप में अपने प्रमाणीकरण/सत्यापन विधियों के रूप में उपयोग क्यों नहीं करते? अंतत:, यह जानना कि _performant_ आपका प्रमाणन कैसा है, आपके ऐप के लिए _good_ होगा क्योंकि प्रमाणीकरण/सत्यापन आपके स्टैक में सबसे बड़ी बाधाओं में से एक है! (यानी _every_ GET/POST/PUT/DELETE _request_ को प्रमाणन/सत्यापन से गुजरना पड़ता है, इसलिए इसे कुछ मिलीसेकंड से अधिक नहीं लेना चाहिए ... इससे अधिक और आपका ऐप _नहीं होगा स्केल_!)

याद रखें : कुछ भी न मानें _ और अपने आवेदन का परीक्षण करने के लिए यह कैसे समझ में आता है, इस पर अपना निर्णय लें। यदि परीक्षण करने का "सही तरीका" होता, तो सभी विश्वविद्यालय इसे पढ़ा रहे होते ... ऐसा नहीं है। "सबसे अच्छा तरीका" "_pragmatic_" दृष्टिकोण है; वह करें जो _your_ प्रोजेक्ट के लिए समझ में आता है।

उम्मीद है की वो मदद करदे। यदि नहीं, तो कृपया हमें बताएं कि आप कहां फंस गए हैं! :+1:

तुम दोनों को धन्यवाद! यह अविश्वसनीय रूप से सहायक है। आपके सुझाव के आधार पर मुझे लगता है कि यह सेटअप एकीकरण परीक्षण के लिए उधार देता है - मैं निश्चित रूप से जानना चाहता हूं कि ये टुकड़े एक साथ काम कर रहे हैं या नहीं।

मैं केवल अपनी प्रमाणीकरण विधि के रूप में oAuth का उपयोग कर रहा हूं (कोई उपयोगकर्ता नाम/पासवर्ड नहीं)। मुझे परीक्षण क्लाइंट बनाने के तरीके के बारे में और जानने में दिलचस्पी है। मुझे पता है कि मैं पूरे oAuth प्रवाह से नहीं गुजरना चाहता, लेकिन जैसा कि आपने एक टोकन हार्डकोड करने का सुझाव दिया था जिसे मैं अपने परीक्षणों में उपयोग कर सकता हूं। क्या आप किसी ऐसे संसाधन की सिफारिश कर सकते हैं जो मुझे परीक्षण क्लाइंट बनाने के लिए अपना सिर लपेटने में मदद कर सके?

अगर यह मेरी वर्तमान परियोजना SailJS v11.0.1 का उपयोग करने में मदद करता है। मेरे पास बूटस्ट्रैप परीक्षण फ़ाइल है जो मेरे सर्वर को प्रारंभ करती है और फिक्स्चर के साथ इन-मेमोरी डेटाबेस बनाता/पॉप्युलेट करती है। क्या यह परीक्षण क्लाइंट बनाने के लिए उपयुक्त स्थान हो सकता है?

फिर से धन्यवाद -- अपने ज्ञान को साझा करने के लिए इतने इच्छुक लोगों को ढूंढना अद्भुत है।

@ rhewitt22 , ठीक है, मेरे मामले में परीक्षण क्लाइंट सही पेलोड और गुप्त कुंजी के साथ हस्ताक्षरित एक गैर-समाप्ति जेडब्ल्यूटी टोकन बनाने जितना आसान था। शायद यह मदद करता है।

OAuth में, मुझे लगता है कि यह प्रमाणीकरण प्रवाह पर निर्भर करता है। हो सकता है कि आप कुछ अनुमतियों के साथ अंतिम एक्सेस टोकन भी बना सकते हैं और वह समाप्त नहीं होता है, इसलिए आपको हर बार प्रवाह से गुजरना नहीं पड़ता है।

अपने परीक्षणों में एक गैर-समाप्ति टोकन को हार्डकोड करने के बारे में सुरक्षा चिंताओं से सावधान रहें, यदि वह टोकन भी उत्पादन प्रणाली में बहुत सारी अनुमति देता है। तब एक संभावित हमलावर को पहुंच प्राप्त करने के लिए केवल इस टोकन की आवश्यकता होगी। हो सकता है कि आप कुछ क्लाइंट को एक्सेस प्रदान करने का कोई तरीका चाहते हों, और परीक्षण चलाते समय आप अपने परीक्षण क्लाइंट या टोकन तक पहुंच प्रदान कर सकते हैं। मुझे आशा है कि यह सब समझ में आता है।

@दीवारिंग

सलाह के लिए धन्यवाद!

मैंने अभी आगे बढ़कर एक नकली उपयोगकर्ता बनाया, मेरे परीक्षणों में oAuth प्रवाह को छोड़ दिया और उन्हें वही JWT (समाप्ति के साथ) दिया जो मैं उत्पादन में उपयोग करता हूं। मेरे सभी परीक्षण पास हो रहे हैं, और मैं बहुत खुश टूरिस्ट हूं।

:मुस्कुराना: :मुस्कुराना: :मुस्कुराना:

मुझे लगता है कि जैसा कि मैं अपने ऐप पर काम कर रहा हूं और विकास सर्वर को देख रहा हूं, मैं यह सुनिश्चित कर रहा हूं कि ओएथ भाग अपेक्षित रूप से काम करता है।