أفضل الطرق لاختبار التطبيقات الخاصة بك دون خادم

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

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

هذا أليكس

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

آنا وجيف يتحدثان دائمًا عن هذا الشيء بدون خادم

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

يناقش فريق أليكس استخدام السيرفر في مشروعهم الجديد

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

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

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

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

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

اختبار محلي

مع التطبيقات الخالية من الخوادم ، لا تدير البنية الأساسية. تبدو رائعة ، ولكن كيف يمكنك تشغيل التطبيق الخاص بك محليا؟ هل يمكنك القيام بذلك؟

أول حاجز على الطريق: كيف تقوم بتشغيل تطبيق بدون خادم محليًا؟

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

  • الأدوات الأساسية لوظائف Azure (لوظائف Azure)
  • AWS SAM CLI (لتطبيقات AWS Lambda المصممة باستخدام AWS SAM)
  • أدوات الجهة الخارجية (أي ، localstack)
  • عامل ميناء لامدا ل AWS المحاكاة المحلية
  • تشغيل Node.js تعمل محليا

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

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

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

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

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

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

حاجز الطريق الثاني: كيف يؤثر السيرفر على الاختبار الآلي؟

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

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

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

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

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

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

اختبار الهرم مع الاختبار اليدوي

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

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

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

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

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

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

خادم

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

كيفية كتابة وظائف serverless قابلة للاختبار

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

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

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

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

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

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

إحدى الطرق الرائعة للقيام بذلك هي تطبيق Hexagonal Architecture على وظائفك بدون خادم.

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

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

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

بما أن أليكس وفريقه يستخدمون AWS ، فقد انتهوا بهيكل مثل التالي:

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

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

وحدة التجارب

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

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

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

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

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

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

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

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

التمثيل المرئي لوظيفة AWS Lambda مع الاختبارات

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

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

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

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

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

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

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

استخدام وظائف AWS Lambda لموازنة اختبارات واجهة المستخدم

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

CI / CD

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

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

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

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

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

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

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

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

بعد الاختبار

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

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

طاقم الواعظين بدون خادم حصل على عضو جديد

بعد النصي

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

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

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

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

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

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

Desole ، تتبع الأخطاء مفتوحة المصدر ، متكامل بإحكام مع AWS
يتم إنشاء جميع الرسوم التوضيحية باستخدام تطبيق SimpleDiagrams4.

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

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