اختبار Node.js المشاريع. الجزء 1. اختبار تشريح وأنواع الاختبار

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



على وجه الخصوص ، سوف يركز على اختيار أنواع الاختبار المناسبة في موقف معين ، وعلى تصميمها الصحيح ، وتقييم فعاليتها ، وعلى المكان الذي تحتاج فيه بالضبط إلى سلاسل CI / CD لوضعها. تم توضيح بعض الأمثلة هنا باستخدام Jest ، والبعض الآخر يستخدم Mocha. هذه المادة لا تركز بشكل أساسي على الأدوات ، ولكن على منهجية الاختبار.

→ اختبار Node.js المشاريع. الجزء 2. اختبار تقييم الأداء ، والتكامل المستمر وتحليل جودة الرمز

▍0. القاعدة الذهبية: يجب أن تكون الاختبارات بسيطة ومباشرة

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

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

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

القسم 1. تشريح الاختبارات

▍1. صمم اختباراتك حتى يخبرك التقرير بما يجري اختباره ، وفي أي سيناريو ، وما هو متوقع من الاختبارات

توصيات

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

1. ما الذي يتم اختباره بالضبط؟ على سبيل المثال ، أسلوب ProductsService.addNewProduct .
2. في أي سيناريو وتحت أي ظروف يتم إجراء الاختبار؟ على سبيل المثال ، يتم فحص رد فعل النظام في موقف لا يتم فيه تمرير سعر البضاعة إلى الطريقة.
3. ما هي نتائج الاختبار المتوقعة؟ على سبيل المثال ، في موقف مماثل ، يرفض النظام تأكيد إضافة منتج جديد إليه.

عواقب الانحراف عن التوصيات

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

النهج الصحيح

تتكون معلومات الاختبار من ثلاثة أجزاء من المعلومات.

 //1.   describe('Products Service', function() { //2.  describe('Add new product', function() {   // 3. ,       it('When no price is specified, then the product status is pending approval', ()=> {     const newProduct = new ProductService().add(...);     expect(newProduct.status).to.equal('pendingApproval');   }); }); }); 

النهج الصحيح

يشبه تقرير الاختبار مستندًا يحتوي على بيان بمتطلبات المنتج.

إليك كيف يبدو على مستويات مختلفة.


وثيقة متطلبات المنتج ، تسمية الاختبار ، نتائج الاختبار

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

▍2. صف ما تتوقعه من الاختبارات في لغة المنتج: استخدم عبارات نمط BDD

توصيات

إن تطوير الاختبارات بأسلوب تعريفي يسمح لأولئك الذين يعملون معهم بإدراك جوهرهم على الفور. إذا كانت الاختبارات مكتوبة باستخدام مقاربة حتمية ، فهي مليئة بنيات مشروطة تعقد إلى حد كبير فهمهم. باتباع هذا المبدأ ، ينبغي أن توصف التوقعات بلغة قريبة من المعتاد. يستخدم النمط BDD التعريفي تصميمات expect أو should ، بدلاً من بعض التعليمات البرمجية الخاصة لتصميمها. إذا لم تكن هناك بيانات ضرورية في Chai أو Jest ، واتضح أن هذه العبارات مطلوبة غالبًا ، ففكر في إضافة "اختبارات" جديدة إلى Jest أو كتابة المكونات الإضافية الخاصة بك لـ Chai .

عواقب الانحراف عن التوصيات

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

نهج خاطئ

سيضطر قارئ هذا الاختبار إلى مراجعة الكود الإلزامي الطويل بشكل كامل فقط لفهم ما الذي يتم اختباره بالضبط في الاختبار.

 it("When asking for an admin, ensure only ordered admins in results" , ()={   //,       — "admin1"  "admin2",   "user1"   const allAdmins = getUsers({adminOnly:true});   const admin1Found, adming2Found = false;   allAdmins.forEach(aSingleUser => {       if(aSingleUser === "user1"){           assert.notEqual(aSingleUser, "user1", "A user was found and not admin");       }       if(aSingleUser==="admin1"){           admin1Found = true;       }       if(aSingleUser==="admin2"){           admin2Found = true;       }   });   if(!admin1Found || !admin2Found ){       throw new Error("Not all admins were returned");   } }); 

النهج الصحيح

يمكنك فهم هذا الاختبار حرفيًا في لمحة.

 it("When asking for an admin, ensure only ordered admins in results" , ()={   //,        const allAdmins = getUsers({adminOnly:true});     expect(allAdmins).to.include.ordered.members(["admin1" , "admin2"]) .but.not.include.ordered.members(["user1"]); }); 

.3. أداء اختبار رمز الوبر باستخدام الإضافات الخاصة

توصيات

هناك مجموعة من المكونات الإضافية لـ ESLint المصممة خصيصًا لتحليل رمز الاختبار وللعثور على مشاكل في هذا الرمز. على سبيل المثال ، سوف يقدم المكون الإضافي eslint-plugin-mocha تحذيرات إذا كان الاختبار مكتوبًا على المستوى العالمي (وليس سليلًا describe() ) ، أو إذا تبين أن الاختبارات قد تم تخطيها ، مما قد يعطي آمالًا خاطئة بأن جميع الاختبارات قد انتهت. يعمل البرنامج المساعد eslint-plugin-jest بطريقة مشابهة ، على سبيل المثال ، التحذير من الاختبارات التي لا تحتوي على عبارات ، أي تلك التي لا تتحقق من أي شيء.

عواقب الانحراف عن التوصيات

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

نهج خاطئ

سيناريو الاختبار مليء بالأخطاء ، والتي ، لحسن الحظ ، يمكن اكتشافها باستخدام linter.

 describe("Too short description", () => { const userToken = userService.getDefaultToken() // *error:no-setup-in-describe, use hooks (sparingly) instead it("Some description", () => {});//* error: valid-test-description. Must include the word "Should" + at least 5 words }); it.skip("Test name", () => {// *error:no-skipped-tests, error:error:no-global-tests. Put tests only under describe or suite expect("somevalue"); // error:no-assert }); it("Test name", () => {*//error:no-identical-title. Assign unique titles to tests }); 

▍4. التمسك طريقة الصندوق الأسود - اختبار فقط الأساليب العامة

توصيات

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

عواقب الانحراف عن التوصيات

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

نهج خاطئ

يختبر هذا الاختبار الآليات الداخلية للفصل بدون سبب محدد لمثل هذه الفحوصات.

 class ProductService{ //      //     ,      calculateVAT(priceWithoutVAT){   return {finalPrice: priceWithoutVAT * 1.2};   //           } //  getPrice(productId){   const desiredProduct= DB.getProduct(productId);   finalPrice = this.calculateVATAdd(desiredProduct.price).finalPrice; } } it("White-box test: When the internal methods get 0 vat, it return 0 response", async () => {   //       VAT,      .  ,   ,        expect(new ProductService().calculateVATAdd(0).finalPrice).to.equal(0); }); 

▍5. اختر كائنات النسخ الاحتياطي المناسبة: تجنب الغوغاء ، مفضلاً الرهانات والجواسيس

توصيات

يتضاعف استخدام الاختبار عندما يكون الاختبار شرًا ضروريًا ، حيث إنه يرتبط بالآليات الداخلية للتطبيق. بدون البعض منهم ، من المستحيل القيام به. هنا مواد مفيدة حول هذا الموضوع. ومع ذلك ، لا يمكن استدعاء الطرق المختلفة لاستخدام مثل هذه الكائنات مكافئة. لذا ، فإن بعضًا منها - كعب الرهبة (كعب الرهبة) والجواسيس (الجاسوس) ، تهدف إلى اختبار متطلبات المنتج ، ولكن ، كأثر جانبي لا مفر منه ، يتم إجبارهم على التأثير قليلاً في الآليات الداخلية لهذا المنتج. تهدف Mocks ، من ناحية أخرى ، إلى اختبار الآليات الداخلية للمشروع. لذلك ، يؤدي استخدامها إلى تحميل كبير غير ضروري على المبرمجين ، والذي تحدثنا عنه أعلاه ، وعرضًا على التقيد بمنهجية "الصندوق الأسود" عند كتابة الاختبارات.

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

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

عواقب الانحراف عن التوصيات

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

نهج خاطئ

يوضح هذا المثال كائنًا وهميًا يركز على اختبار الآليات الداخلية للتطبيق.

 it("When a valid product is about to be deleted, ensure data access DAL was called once, with the right product and right config", async () => {   //,        const dataAccessMock = sinon.mock(DAL);   // ,           dataAccessMock.expects("deleteProduct").once().withArgs(DBConfig, theProductWeJustAdded, true, false);   new ProductService().deletePrice(theProductWeJustAdded);   mock.verify(); }); 

النهج الصحيح

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

 it("When a valid product is about to be deleted, ensure an email is sent", async () => {   //,        const spy = sinon.spy(Emailer.prototype, "sendEmail");   new ProductService().deletePrice(theProductWeJustAdded);   //  .       ? ,               (  ) }); 

▍6. أثناء الاختبار ، استخدم مدخلات واقعية ، لا تقتصر على شيء مثل "فو"

توصيات

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

عواقب الانحراف عن التوصيات

عند اختبار مشروع أثناء تطويره ، لا يمكن اجتياز جميع الاختبارات إلا إذا تم تنفيذها باستخدام بيانات غير واقعية مثل الخطوط "foo". ولكن في الإنتاج ، سوف يفشل النظام في موقف حيث يعطيها المتسلل شيء مثل @3e2ddsf . ##' 1 fdsfds . fds432 AAAA @3e2ddsf . ##' 1 fdsfds . fds432 AAAA @3e2ddsf . ##' 1 fdsfds . fds432 AAAA .

نهج خاطئ

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

 const addProduct = (name, price) =>{ const productNameRegexNoSpace = /^\S*$/;//  if(!productNameRegexNoSpace.test(name))   return false;// , -   ,  .     //  -    return true; }; it("Wrong: When adding new product with valid properties, get successful confirmation", async () => {   // "Foo",    ,    ,    false   const addProductResult = addProduct("Foo", 5);   expect(addProductResult).to.be.true;   // :     - ,     //         }); 

النهج الصحيح

ويستخدم بيانات عشوائية مماثلة لبيانات حقيقية.

 it("Better: When adding new valid product, get successful confirmation", async () => {   const addProductResult = addProduct(faker.commerce.productName(), faker.random.number());   //   : {'Sleek Cotton Computer',  85481}   expect(addProductResult).to.be.true;   //  ,         ,    .   //     ,    ! }); 

▍ 7. أنظمة الاختبار باستخدام مجموعات الإدخال متعددة باستخدام اختبار المستندة إلى الخاصية

توصيات

عادةً ما تستخدم الاختبارات مجموعات صغيرة من بيانات الإدخال. حتى لو كانت تشبه البيانات الحقيقية (تحدثنا عن ذلك في القسم السابق) ، فإن مثل هذه الاختبارات تغطي فقط عددًا محدودًا للغاية من المجموعات المحتملة لمدخلات الكيان الذي تم التحقيق فيه. على سبيل المثال ، قد يبدو كالتالي: (method('', true, 1), method("string" , false" , 0)) . المشكلة هي أنه في واجهة برمجة تطبيقات الإنتاج ، والتي تسمى بخمس معلمات ، يمكن الحصول عليها إدخال آلاف المتغيرات المختلفة لمجموعاتها ، إحداها يمكن أن تؤدي إلى فشل (سيكون من المناسب تذكر التضمين هنا ). ماذا لو كان بإمكانك كتابة اختبار واحد يتحقق تلقائيًا من طريقة معينة بحثًا عن 1000 مجموعة من مدخلاته ومعرفة أي منها هل تستجيب الطريقة بشكل غير صحيح؟ الاختبار على أساس التحقق من الممتلكات هو بالضبط ما لنا في مثل هذه الحالة هو مفيد. وهي، في سياق هذا اختبار وحدة الشيكات، واصفا إياه مع كل مزيج ممكن من البيانات المدخلة، مما يزيد من احتمال العثور على عدد قليل من البق. لنفترض أن لدينا طريقة addNewProduct(id, name, isDiscount) ، ومكتبة أداء الاختبار ، يستدعي ذلك مع العديد من مجموعات من المعلمات الرقمية ، سلسلة ونوع منطقي ، على سبيل المثال - (1, "iPhone", false) ، (2, "Galaxy", true) . من الممكن إجراء الاختبار بناءً على التحقق من الخاصية باستخدام بيئة تنفيذ الاختبار المعتادة (Mocha ، Jest ، وما إلى ذلك) واستخدام مكتبات متخصصة مثل js- check أو testcheck (تحتوي هذه المكتبة على وثائق جيدة جدًا).

عواقب الانحراف عن التوصيات

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

النهج الصحيح

اختبار العديد من خيارات الإدخال باستخدام مكتبة mocha-testcheck.

 require('mocha-testcheck').install(); const {expect} = require('chai'); const faker = require('faker'); describe('Product service', () => { describe('Adding new', () => {   //  100         check.it('Add new product with random yet valid properties, always successful',     gen.int, gen.string, (id, name) => {       expect(addNewProduct(id, name).status).to.equal('approved');     }); }) }); 

8. حاول أن يكون رمز الاختبار مكتفياً ذاتياً ، مما يقلل من المساعدات الخارجية والتجريد

توصيات

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

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

عواقب الانحراف عن التوصيات

, 4 , 2 , ? ! , , .

. ?

 test("When getting orders report, get the existing orders", () => {   const queryObject = QueryHelpers.getQueryObject(config.DBInstanceURL);   const reportConfiguration = ReportHelpers.getReportConfig();//   ?        userHelpers.prepareQueryPermissions(reportConfiguration);//  ?         const result = queryObject.query(reportConfiguration);   assertThatReportIsValid();//  ,           -    expect(result).to.be.an('array').that.does.include({id:1, productd:2, orderStatus:"approved"});   //      ?        }) 

النهج الصحيح

, .

 it("When getting orders report, get the existing orders", () => {   // ,           const orderWeJustAdded = ordersTestHelpers.addRandomNewOrder();   const queryObject = newQueryObject(config.DBInstanceURL, queryOptions.deep, useCache:false);   const result = queryObject.query(config.adminUserToken, reports.orders, pageSize:200);   expect(result).to.be.an('array').that.does.include(orderWeJustAdded); }) 

▍9. :

توصيات

, , , , . . , ( ) . — , ( , ). — , , , , . , , . — , , , , ( , , , ).

عواقب الانحراف عن التوصيات

, . . . . , , , .

. , .

 before(() => { //       .   ? - ,  -   json-. await DB.AddSeedDataFromJson('seed.json'); }); it("When updating site name, get successful confirmation", async () => { // ,  ,  "Portal", ,           const siteToUpdate = await SiteService.getSiteByName("Portal"); const updateNameResult = await SiteService.changeName(siteToUpdate, "newName"); expect(updateNameResult).to.be(true); }); it("When querying by site name, get the right site", async () => { // ,  ,  "Portal", ,           const siteToCheck = await SiteService.getSiteByName("Portal"); expect(siteToCheck.name).to.be.equal("Portal"); //!      :[ }); 

النهج الصحيح

, , .

 it("When updating site name, get successful confirmation", async () => { //           const siteUnderTest = await SiteService.addSite({   name: "siteForUpdateTest" }); const updateNameResult = await SiteService.changeName(siteUnderTest, "newName"); expect(updateNameResult).to.be(true); }); 

▍10. , . expect

توصيات

, , try-catch-finally catch . , , , .

Chai, expect(method).to.throw . Jest: expect(method).toThrow() . , . , , .

عواقب الانحراف عن التوصيات

, , , .

, try-catch .

 it("When no product name, it throws error 400", async() => { let errorWeExceptFor = null; try { const result = await addNewProduct({name:'nest'});} catch (error) { expect(error.code).to.equal('InvalidInput'); errorWeExceptFor = error; } expect(errorWeExceptFor).not.to.be.null; //    ,         //  ,     null,       }); 

النهج الصحيح

expect , , .

 it.only("When no product name, it throws error 400", async() => { expect(addNewProduct)).to.eventually.throw(AppError).with.property('code', "InvalidInput"); }); 

▍11. ,

توصيات

. , (smoke test), -, , . - . , , , #cold , #api , #sanity . . , Mocha -g ( --grep ).

عواقب الانحراف عن التوصيات

, , , , , , . .

النهج الصحيح

#cold-test , . , -, , — .

 //    ( ,    ),     // ,        //   describe('Order service', function() { describe('Add new order #cold-test #sanity', function() {   it('Scenario - no currency was supplied. Expectation - Use the default currency #sanity', function() {     //-    }); }); }); 

▍12.

توصيات

, Node.js-. , , Node.js .

TDD — , , . , . , , Red-Green-Refactor . , - , , , , , . , . ( — , , ).

عواقب الانحراف عن التوصيات

— , . .

2.

▍13. ,

توصيات

, , 10 , . , . , . , (, ), , , , ? - ?

, . , 2019 , , TDD, — , . , , , . , IoT-, , , - Kafka RabbitMQ, . - , , , . , , , , ? (, , Alexa) , , .

, ( ). , , , , , , . , , - API — Consumer-Driven Contracts . , , , , . , , , , , . , , .

, TDD . , TDD , . , , , .

عواقب الانحراف عن التوصيات

— ( ), .

النهج الصحيح

. . , , Node.js, .

▍14. ,

توصيات

. — . , , . , , - , , - ? , . , : TDD, — .

«». API, - , (, , , , , ). , , , (, ). , , , , , , .

عواقب الانحراف عن التوصيات

, , , , 20.

النهج الصحيح

supertest , API, Express, .


API, Express

▍15. , API, Consumer-Driven Contracts

توصيات

, , , , . , , - , , , - . «-22» : . , , . , Consumer-Driven Contracts PACT .

. . PACT , ( «»). , , PACT, , , . , , , , .

عواقب الانحراف عن التوصيات

.

النهج الصحيح

Consumer-Driven Contracts

, , B , . B .

▍16.

توصيات

(middleware) - , , - , Express-. . , , . , , JS- {req,res} . , «» (, Sinon ) , {req,res} . , , , . node-mock-http , , , . , , HTTP-, -.

عواقب الانحراف عن التوصيات

Express .

النهج الصحيح

Express-.

 // ,     const unitUnderTest = require('./middleware') const httpMocks = require('node-mocks-http'); //  Jest,     Mocha    describe()  it() test('A request without authentication header, should return http status 403', () => { const request = httpMocks.createRequest({   method: 'GET',   url: '/user/42',   headers: {     authentication: ''   } }); const response = httpMocks.createResponse(); unitUnderTest(request, response); expect(response.statusCode).toBe(403); }); 

▍17.

توصيات

, , , , , , . , , - . , , , ( , , ), , ( — ) . , : SonarQube ( 2600 GitHub) Code Climate ( 1500 ).

عواقب الانحراف عن التوصيات

, , . . , .

النهج الصحيح

Code Climate.


Code Climate

▍18. , Node.js

توصيات

, , . , , , - , . , - , , , , ? , , ? , API ?

Netflix - . , , , , . , - — Chaos Monkey . , , , . Kubernetes — kube-monkey . , Node.js? , , , V8 1.7 . . node-chaos , -.

عواقب الانحراف عن التوصيات

, , , .

النهج الصحيح

npm- chaos-monkey , Node.js.


chaos-monkey

ملخص

, Node.js-. , . .

أعزائي القراء! - ?