أفضل الطرق لاختبار التطبيقات التي لا تحتاج إلى خادم

Serverless هو أكثر من مجرد نموذج لتنفيذ الحوسبة السحابية. إنه يغير الطريقة التي نخطط بها ونبني وننشر التطبيقات. ولكنه يغير أيضًا الطريقة التي نختبر بها تطبيقاتنا.

قابل أليكس. Alex هو مطور JavaScript عادي ، ركز على Node.js مؤخرًا.

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

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

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

في تلك اللحظة ، تبدو عمليتهم كما يلي:

  1. يحللون ميزة جديدة.
  2. بالنسبة إلى الميزات الأقل تعقيدًا ، يبدأون بالشفرة ، ثم يقومون بتشغيلها محليًا وإضافة بعض الاختبارات في النهاية.
  3. للحصول على ميزات أكثر تعقيدًا ، يقومون بعمل نسختهم من TDD: يبدأون بالاختبارات ، ثم يكتبون الكود ويختبرونه محليًا.
  4. عندما تكون الميزة جاهزة ، تنتقل إلى أداة CI التي تنشرها في بيئة الاختبار.
  5. ثم يأخذ فريق ضمان الجودة ميزة جديدة لإجراء جولة أخرى من الاختبار اليدوي. إذا كان كل شيء يبدو جيدًا ، فإن التطبيق ينتقل عبر CI إلى الإنتاج.

قرروا البدء خطوة بخطوة ، ثم حل المشاكل كما واجهوها.

اختاروا ميزة صغيرة ، ولأنها كانت بسيطة ، فقد بدأوا بالشفرة. عندما كان جزء الترميز جاهزًا ، واجهوا الحاجز الأول: كيف يمكنك تشغيل التطبيقات بدون خادم محليًا؟

الاختبار المحلي

مع تطبيقات بدون خادم ، لا يمكنك إدارة البنية التحتية. يبدو رائعًا ، ولكن كيف يمكنك تشغيل التطبيق محليًا بعد ذلك؟ يمكنك حتى فعل ذلك؟

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

  • الأدوات الأساسية لوظائف Azure (لوظائف Azure)
  • AWS SAM CLI (لتطبيقات AWS Lambda المصممة باستخدام AWS SAM)
  • أدوات الطرف الثالث (مثل localstack)
  • docker-lambda لمحاكاة AWS Lambda المحلية
  • قم بتشغيل وظيفة Node.js محليًا

بالطبع ، القائمة ليست كاملة - هناك المزيد من الأدوات ، ونرى أدوات جديدة كل يوم تقريبًا الآن.

معظم هذه الأدوات لها قيود معينة. يمكنهم محاكاة وظائف بدون خادم وبعض الخدمات الأخرى ، مثل بوابة API. ولكن ماذا عن الأذونات وطبقة المصادقة والخدمات الأخرى؟

يساعد الاختبار المحلي في عمليات التحقق السريعة للتأكد من أن وظيفتك تعمل. ولكن هل هناك طريقة أفضل للتأكد من أن تطبيقك الذي لا يحتوي على خادم يعمل على النحو المنشود؟ نعم هنالك. الخطوة الأولى والأكثر أهمية هي: كتابة الاختبارات.

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

الاختبارات الآلية

انتقل أليكس وفريقه للتو إلى Jest لاختبار تطبيقاتهم Node.js. لا يزالون يقومون بالكثير من الواجهة الأمامية ، لذلك يريدون استخدام نفس الأدوات للمكدس الكامل كلما أمكنهم ذلك. هل يمكنهم استخدام Jest لاختبار التطبيقات بدون خادم أيضًا؟ وماذا يجب أن يختبروا؟

بعد تحقيق سريع ، أدركوا أنه يمكنهم استخدام أدوات اختبار Node.js المفضلة لديهم. تعمل Jest و Jasmine و Mocha وغيرها بشكل جيد مع خادم.

ما الذي يجب عليك اختباره في تطبيق بدون خادم؟

من خلال تطبيقات Node.js الخاصة بهم ، يتبع Alex وفريقه هرم الأتمتة للاختبار ذي المستويات الثلاثة. تم ذكر هرم الاختبار لأول مرة بواسطة مايك كون في كتابه "النجاح مع رشاقة".

كما يحدد هرم الاختبار ، لديهم:

  • الكثير من اختبارات الوحدة ، لأنها أرخص (أسرع في الكتابة والتشغيل)
  • اختبارات تكامل أقل ، لأنها أكثر تكلفة وتستغرق وقتًا أطول للتشغيل
  • عدد قليل من اختبارات واجهة المستخدم ، لأنها الأغلى تكلفة (تتطلب بعض أدوات واجهة المستخدم الرسومية) والأبطأ في التشغيل

إلى جانب ذلك ، لديهم أيضًا اختبارًا يدويًا قائمًا على الجلسة ، يقوم به فريق ضمان الجودة.

كيف يؤثر عدم وجود خادم على هرم أتمتة الاختبار؟

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

لا تتأثر طبقة اختبارات الوحدة كثيرًا. لا تزال اختبارات الوحدة هي الأرخص في الكتابة والتشغيل ، ولكن يمكن أن تكون الوحدات أصغر.

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

طبقة اختبارات واجهة المستخدم الرسومية هي أيضًا أرخص وأسرع ، بسبب موازاة أرخص.

تبقى طبقة الاختبار اليدوي كما هي. لكن بدون خادم يمكن أن يساعدك على تحسينه قليلاً. سوف ندخل في التفاصيل حول ذلك لاحقًا.

كان لدى أليكس وفريقه في النهاية فكرة عن مكان التركيز. كانت المشكلة التالية هي كيفية كتابة دالة لاختبارها بسهولة أكبر.

كيفية كتابة وظائف بدون خادم قابلة للاختبار

تحتاج إلى التفكير في المخاطر التالية أثناء كتابة دالة بدون خادم:

  • مخاطر التكوين هل قاعدة البيانات والجدول صحيحان؟ أو هل لديك حقوق الوصول؟
  • مخاطر سير العمل الفنيهل تقوم بتحليل واستخدام الطلب الوارد كما ينبغي؟ أم أنك تتعامل مع الردود والأخطاء الناجحة بشكل صحيح؟
  • مخاطر منطق الأعمالهل اتبعت جميع قواعد منطق العمل التي يحتوي عليها تطبيقك؟
  • مخاطر الدمج هل تقرأ بنية الطلبات الواردة بشكل صحيح؟ أم أنك تقوم بتخزين الطلب في قاعدة البيانات بشكل صحيح؟

للتأكد من أن وظيفة عدم وجود خادم تعمل بشكل صحيح ، تحتاج إلى اختبار كل هذه المخاطر.

يمكنك اختبار كل منها كما فعلت في اختبارات التكامل. لكن إعداد الخدمة وتكوينها في كل مرة تريد اختبار أحد هذه المخاطر ليس هو الأمثل. كما يحب صديقي ألكسندر سيموفيتش أن يقول:

تخيل لو تم اختبار السيارات بهذه الطريقة. هذا يعني أنه في كل مرة تريد اختبار برغي واحد أو حتى مرآة في سيارة ، يجب عليك تجميع السيارة بأكملها ثم تفكيكها.

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

واحدة من أفضل الطرق للقيام بذلك هي تطبيق الهندسة السداسيةلوظائفك بدون خادم.

الهندسة السداسية ، أو المنافذ والمحولات ، هي شكل من أشكال بنية التطبيقات التي تعزز فصل الاهتمامات من خلال طبقات المسؤولية. كما يوضح مؤلفها أليستير كوكبيرن:

السماح للتطبيق بأن يتم تشغيله بشكل متساوٍ من قبل المستخدمين أو البرامج أو الاختبار الآلي أو البرامج النصية المجمعة ، وأن يتم تطويره واختباره بمعزل عن أجهزة وقواعد بيانات وقت التشغيل النهائية.

إذن ، كيف ينطبق ذلك على الوظائف التي لا تحتاج إلى خادم؟

نظرًا لأن Alex وفريقه يستخدمون AWS ، فقد انتهى بهم الأمر ببنية مثل ما يلي:

  • يكشف منطق عمل الوظيفة عن عدد قليل من "المنافذ" (أو يتوقع بعض الحجج). على سبيل المثال ، حدث لحدث وارد ، وآخر للتخزين الدائم ، وآخر للإشعارات.
  • لديهم محوّلان للحدث الذي يؤدي إلى تشغيل وظيفة ، أحدهما لمشغل AWS Lambda الحقيقي والآخر للاختبار المحلي.
  • لديهم العديد من المحولات للتخزين الدائم والإشعارات. على سبيل المثال ، محول جدول DynamoDB ومحول في الذاكرة.

كان أليكس وفريقه سعداء لأنهم كانوا يمضون قدمًا. ولكن قبل أن ننتقل ، دعنا نرى كيف تؤثر الهندسة السداسية على كل طبقة من هرم الاختبار.

وحدة التجارب

بقيت اختبارات الوحدة كما هي. لكن من الأسهل كتابة اختبارات الوحدة بسبب الهندسة السداسية. يمكنهم ببساطة استخدام محول محلي أو محاكاة وهمية كمحول لاختبار طبقة عمل الوظيفة بمعزل عن غيرها.

اختبار التكامل

استفادت اختبارات التكامل كثيرًا من الهندسة السداسية. كانوا قادرين على اختبار التكامل الذي يمتلكونه بشكل كامل. تتم محاكاة عمليات تكامل الجهات الخارجية باستخدام محولات أخرى.

كيف يعمل ذلك في الممارسة؟

كل وظائف serverless بهم ديه lambda.js و main.js الملفات. يحتوي الملف الرئيسي على منطق الأعمال لوظيفة بدون خادم. و lambda.js الملف هو المسؤول عن تفخيخ محولات واستدعاء main.js الملف.

يحتوي الملف الرئيسي على وحدته الخاصة واختبارات التكامل. لكن اختبارات التكامل الخاصة به لا تختبر التكامل الكامل مع الخدمات النهائية ، مثل AWS S3 ، لأن ذلك سيبطئها. بدلاً من ذلك ، يستخدمون محولًا في الذاكرة لاختبار الوظيفة مع تكامل تخزين الملفات.

يتم تكامل AWS S3 من خلال FileRepository ، التي لها وحدتها الخاصة واختبارات التكامل. تستخدم فحوصات اختبارات التكامل AWS S3 للتأكد من أن التكامل النهائي يعمل بالفعل.

على عكس main.js ، لا يحتوي ملف lambda.js على اختبارات ، لأنه يحتوي في معظم الأحيان على بضعة أسطر من التعليمات البرمجية.

هذا النهج يشبه التقنية التي يستخدمها فريق MindMup لاختبار الوظائف بدون خادم. باستخدامه ، يمكنك بسهولة اختبار تكامل وظائفك ، والاستمرار في جعل اختبارات التكامل أسرع.

اختبار واجهة المستخدم الرسومية

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

اختبارات واجهة المستخدم باهظة الثمن وبطيئة ، لأنها تعمل في المتصفح. لكن ، بدون خادم رخيص ويتوسع بسرعة.

إذا تمكنوا من تشغيل متصفح في AWS Lambda ، فسيحصلون على موازٍ رخيصة. هذا من شأنه أن يجعل اختبارات واجهة المستخدم الخاصة بهم أرخص وأسرع.

ولكن ، هل يمكنك تشغيل متصفح ، مثل Chrome ، داخل وظيفة بدون خادم؟

نعم! وهو سهل بمساعدة أدوات مثل Serverless Chrome و Chromeless و Puppeteer.

يمكن أن توفر لنا مجموعة من المتصفحات بدون خادم وبدون رأس جيلًا جديدًا من أدوات اختبار واجهة المستخدم. يمكننا بالفعل رؤية بعض منها وتجربتها ، مثل التقييم.

CI / CD

عندما قام Alex وفريقه باختبار أول وظيفة بدون خادم ، فقد حان الوقت لنشر الكود في بيئة الاختبار. أدى ذلك إلى طرح سؤال جديد: كيف يمكنهم استخدام أدوات CI / CD لنشر تطبيقهم بدون خادم؟

الإجابة بسيطة: يمكنهم استخدام أداة CI لتشغيل الاختبارات ونشر التطبيق. لنشر التطبيق ، استخدم أي أداة شائعة ، مثل Claudia.js و AWS SAM و Serverless Framework.

لا يزال بإمكانك استخدام أداة CI المفضلة لديك (مثل Jenkins أو TravisCI أو SemaphoreCI) ، أو إذا كنت تريد الاستمرار في استخدام AWS ، فيمكنك تجربة AWS CodeBuild.

الاختبار اليدوي

حتى من خلال الاختبار اليدوي لا يتأثر بشكل مباشر بالخادم ، وجد الفريق طريقة لتحسين عملية ضمان الجودة.

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

هذا يعني أن وجود بيئة اختبار لم يكن أرخص من أي وقت مضى!

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

ما بعد الاختبار

قام أليكس وفريقه بشحن أول وظيفة بدون خادم إلى مرحلة ما قبل الإنتاج ، وكان الفريق سعيدًا لأنهم تعلموا كيفية اختبار التطبيقات بدون خادم.

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

ما بعد السيناريو

ولكن على الرغم من اختبار التطبيق جيدًا ، حدث شيء ما بين عشية وضحاها.

بعد التحقيق ، اكتشفوا أن أحد عمليات الدمج قد تغير. لقد تعلموا أن الاختبار مهم للتطبيقات بدون خادم ، لكنه ليس كافيًا.

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

لحسن الحظ ، هناك المزيد والمزيد من أدوات المراقبة بدون خادم في السوق كل يوم. بعض الخيارات الجيدة والشائعة هي IOpipe و Thundra و Dashbird و Epsagon.

ولكن ، غالبًا ما تحتوي التطبيقات التي لا تحتوي على خادم على عميل سميك ، مما يعني أن المراقبة الخلفية ليست كافية. أنت بحاجة إلى أداة مماثلة لواجهتك الأمامية. يحتوي هذا السوق على الكثير من الأدوات الرائعة أيضًا ، مثل Sentry و Rollbar.

ولكن بروح عدم وجود خادم ، أنشأنا تطبيقًا مفتوح المصدر لتتبع الأخطاء يسمى Desole. إنه تطبيق بدون خادم يمكنك تثبيته في حساب AWS الخاص بك. إنه يمكّن المؤسسات من تتبع استثناءات وأخطاء التطبيقات دون الحاجة إلى الاختيار بين ملاءمة البرنامج كخدمة وأمان حل مستضاف ذاتيًا. يمكنك التحقق من ذلك هنا: //desole.io.

يتم إنشاء جميع الرسوم التوضيحية باستخدام تطبيق SimpleDiagrams4.

إذا كنت ترغب في معرفة المزيد حول اختبار وبناء تطبيقات بدون خادم باستخدام Node.js و AWS ، فراجع "تطبيقات بدون خادم مع Node.js" ، الكتاب الذي كتبته مع ألكسندر سيموفيتش لـ Manning Publications:

تطبيقات بدون خادم مع Node.js

مقدمة مقنعة لعمليات النشر بدون خادم باستخدام Claudia.js. www.manning.com

سيعلمك الكتاب المزيد حول الاختبار بدون خادم ، مع أمثلة التعليمات البرمجية ، ولكنك ستتعلم أيضًا كيفية إنشاء وتصحيح واجهة برمجة تطبيقات (API) بدون خادم (مع قاعدة البيانات والمصادقة) باستخدام Node و Claudia.js. وستتعلم كيفية إنشاء روبوتات محادثة لـ Facebook Messenger و SMS (باستخدام Twilio) ومهارات Alexa.