Learn-json-web-tokens: اختبار API الذي يستخدم JWTs

حسنًا ، لدي بعض الاقتراحات التي قد تنجح:

1. قم بإعداد عميل _test_ في نظامك وقم بوضع رمز مميز في الاختبارات. استمر في تشغيل المصادقة.
2. تأكد من إيقاف تشغيل المصادقة عند إجراء الاختبارات. أعتقد أن هناك طرقًا مختلفة للقيام بذلك. على سبيل المثال ، في Hapi يمكنك استبعاد نظام المصادقة الافتراضي ، وتعيين واحد فقط ، عندما يعمل الخادم بالفعل (ولكن ليس عند تشغيل الاختبارات).
3. اسخر من المكدس ، لذا فأنت تقوم فقط باختبار منطق وحدة التحكم ، دون تقديم طلبات من خلال النظام. قد لا يكون ذلك ممكنًا في بعض الأطر بالرغم من ذلك.

أنا أعمل على بعض الأنظمة حيث اخترنا (1). تبدو الاختبارات بعد ذلك أشبه باختبارات التكامل وليس اختبارات الوحدة ، لأنها تجري خلال المكدس. من ناحية أخرى ، لا يوجد تباين بين بيئة الاختبار والإنتاج.

يمكنك تعيين NODE_ENV=test ، عند تشغيل الاختبارات (معلمة fx. -e في المعمل ) ، إذا كنت تريد تحديد البيئة في التعليمات البرمجية. ومع ذلك ، يجب أن تدرك أن بيئة الاختبار والإنتاج لا تختلف كثيرًا ، وإلا فإنك لا تختبر بالفعل بيئة الإنتاج.

@ rhewitt22 نفضل الطريقة التي وصفهاwalling
(حيث تكون الاختبارات أقرب إلى اختبارات "التكامل" بدلاً من اختبارات "الوحدة")
لهذا السبب _بشكل دقيق_. كل ما تسخر منه هو "_fake_" وبالتالي لن تعرف متى يعمل شيء "_real_" أم لا (_ ومن ثم فإن الأخطاء أكثر احتمالًا_).

لقد ورثنا (_كبير_) مشاريع حيث _ ينسى الناس _ أن يقوموا بتحديث النماذج عندما يغيرون الأساليب ونتيجة لذلك لا تعكس الاختبارات _ الواقعية _ ؛ _ كابوس التصحيح _!

اسأل نفسك دائمًا: "_ ( لماذا ) نحتاج أن نسخر من هذا ؟ _"

إذا كنت تسخر من شيء ما لأنه خارج عن سيطرتك ، على سبيل المثال خدمة أو جهاز شبكة تابع لجهة خارجية ،
يبدو الأمر معقولا. ولكن إذا كنت تسخر من المكدس الخاص بك ،

الدليل الموجود في السؤال _ الخاص بك هو في المصطلح " نقطة نهاية _".

اضغط على نقطة النهاية وإذا حصلت على 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/when-should-i-mock

TL ؛ د

إذا كانت الشفرة _own_ الخاصة بك معقدة للغاية وتشعر أنك بحاجة إلى السخرية منها ، _ أولاً قم بتبسيط الكود الخاص بك _ !!

أيضًا ، كتبنا المكون الإضافي hapi-auth-jwt2 حتى يتمكن الآخرون من الاعتماد على اختباراتنا. وأصدرت مثالاً _خطيًا قابلاً للتطوير_ مدعوم من Redis: https://github.com/dwyl/hapi-auth-jwt2-example بحيث يمكن للأشخاص نسخ ولصق كود (_tested_)! :غمزة:

_ نحن_ نسخر فقط عندما "تشعرنا أن اختباراتنا بطيئة للغاية _" وإلا فإننا _ دائمًا_ نمارس أكبر قدر ممكن من المكدس _ في كل اجتياز اختبار (مع قصر التبعيات على _ الأساسية _ فقط).

إذا كان أحد عناصر وظائف التطبيق الخاص بك يتطلب مصادقة ، فلماذا لا تستخدم ذلك كمنصة _ لممارسة_ أساليب المصادقة / التحقق؟ في النهاية ، معرفة كيف ستكون المصادقة _performant_ الخاصة بك _ جيدة_ لتطبيقك لأن المصادقة / التحقق هي واحدة من أكبر الاختناقات في مجموعتك! (على سبيل المثال ، يجب أن يمر _ كل _ GET / POST / PUT / DELETE _request_ بالمصادقة / التحقق ، لذا يجب ألا يستغرق الأمر أكثر من بضع ملي ثانية ... أكثر من ذلك ولن يتم قياس تطبيقك!)

تذكر : لا تستهلك أي شيء ، وقرر بنفسك كيف يكون من المنطقي اختبار طلبك. إذا كانت هناك "طريقة صحيحة" لإجراء الاختبار ، فستقوم جميع الجامعات بتدريسه ... لا يوجد. "أفضل طريقة" هي نهج "_ البراغماتي_" ؛ افعل ما هو منطقي لمشروعك.

امل ان يساعد. إذا لم يكن كذلك ، فالرجاء إخبارنا أين أنت عالق! : +1:

شكرا لكما! هذا مفيد بشكل لا يصدق. بناءً على اقتراحك ، أعتقد أن هذا الإعداد يفسح المجال لاختبار التكامل - أريد بالتأكيد معرفة ما إذا كانت هذه القطع تعمل معًا.

أنا أستخدم oAuth فقط كطريقة مصادقة (بدون اسم مستخدم / كلمة مرور). أنا مهتم بمعرفة المزيد حول كيفية إنشاء عميل اختبار. أعلم أنني لا أريد المرور عبر تدفق oAuth بالكامل ، ولكن كما اقترحت الرمز الثابت ، رمز مميز يمكنني استخدامه في اختباراتي. هل يمكنك أن توصي بأي موارد قد تساعدني في الالتفاف حول إنشاء عميل اختبار؟

إذا كان ذلك يساعد مشروعي الحالي فيستخدم SailsJS v11.0. لدي ملف اختبار التمهيد الذي يبدأ الخادم الخاص بي وينشئ / يملأ قاعدة بيانات في الذاكرة بالتركيبات. هل يمكن أن يكون هذا مكانًا مناسبًا لإنشاء عميل اختبار؟

شكرًا لك مرة أخرى - إنه لأمر رائع أن تجد أشخاصًا على استعداد لمشاركة معارفهم.

@ rhewitt22 ، حسنًا ، في حالتي ، كان عميل الاختبار بسيطًا مثل إنشاء رمز JWT غير منتهي الصلاحية موقّعًا بالحمولة الصحيحة والمفتاح السري. ربما يساعد ذلك.

في OAuth ، أعتقد أن ذلك يعتمد على تدفق المصادقة. ربما يمكنك حتى إنشاء رمز الوصول النهائي بأذونات معينة والتي لا تنتهي صلاحيتها ، لذلك لا يتعين عليك المرور عبر التدفق في كل مرة.

احذر من المخاوف الأمنية المتعلقة بترميز ثابت غير منتهي الصلاحية في اختباراتك ، إذا كان هذا الرمز يمنحك أيضًا الكثير من الأذونات في نظام الإنتاج. بعد ذلك ، سيحتاج المهاجم المحتمل فقط هذا الرمز المميز للوصول. قد ترغب في طريقة ما لمنح الوصول لعملاء معينين ، وعند إجراء الاختبارات ، يمكنك منح حق الوصول إلى عميل الاختبار أو الرمز المميز الخاص بك. آمل أن يكون كل شيء منطقيًا.

walling

شكرا على النصيحة!

لقد تقدمت للتو وأنشأت مستخدمًا مزيفًا ، وتخطيت تدفق oAuth ، في اختباراتي ومنحتهم نفس JWT (مع انتهاء الصلاحية) الذي أستخدمه في الإنتاج. لقد نجحت جميع اختباراتي ، وأنا سعيد للغاية.

:ابتسامة ابتسامة ابتسامة:

أعتقد أنه أثناء عملي على تطبيقي والنظر إلى خادم التطوير ، سأضمن أن جزء oAuth يعمل كما هو متوقع.