ما هي أطر الاختبار التي يمكن استخدامها لـ Node؟ ستشاركك المقالة التالية بعض أطر عمل اختبار Node.js وآمل أن تكون مفيدة لك! 
دورة المقدمة السريعة لـ Node.js: أدخل لتتعلم
ملاحظة المحرر: مؤلف هذا المقال هو Tianzhu، وهو مهندس Node.js في Ant Group، وسيقدم أولاً مكتبات الفئات شائعة الاستخدام في كل جزء، وفي نهاية المقالة، سيناقش ما إذا كان اختبار الوحدة ضروريًا أم لا للمناقشة معا.
يشيع استخدام الموكا والدعابة. لا يزال اختبار العقدة الرسمي الجديد قيد الصقل، والمستقبل واعد.
$موكا اختبار/egg-view-ejs.test.js يجعل ✓ ينبغي تقديمها مع السكان المحليين ✓ يجب تقديمه مع ذاكرة التخزين المؤقت ✓ ينبغي تقديمه مع التخطيط ✓ يجب تقديم الخطأ renderString ✓ يجب تقديم سلسلة مع البيانات ✓ يجب تقديم خطأ في السلسلة 6 تمريرات (398 مللي ثانية)
على الرغم من وجود عدد كبير جدًا من العدائين، إلا أن معايير الإنتاج الخاصة بهم كلها بتنسيق TAP، ويتم إخراج النتائج من خلال مراسلين مختلفين.
مجرد كتابة اختبار واحد لا يكفي، نحتاج إلى معرفة ما إذا كانت جميع العمليات الفرعية للكود مغطاة، لذلك نحتاج عادةً إلى استخدام أدوات تغطية الكود.
لقد كان من قبل istanbuljs، ولكن لاحقًا أعاد المؤلف كتابة nyc. وهم يتحملون بشكل أساسي مسؤوليتين: الأولى هي ترجمة الكود لإدراج كود التراكم، والأخرى هي دعم المراسلين المختلفين لإنشاء تقارير التغطية.
في وقت لاحق، V8 المدمج في إحصائيات التغطية
أي أنه ليست هناك حاجة لترجمة الكود بعد الآن، ويتم دعم جمع بيانات التغطية محليًا.
ثم كتب هذا المؤلف c8 يركز على إنشاء تقارير التغطية.
للتحقق من النتائج المتغيرة، يعد التأكيد ضروريًا.
تاريخيًا: توقع.js، ينبغي.js، تشاي وتأكيد السلطة، لدى jest أيضًا توقعًا مدمجًا خاصًا بها.
ولكن الآن أصبح التأكيد/الصرامة الرسمي لـ Node.js أمرًا جيدًا بالفعل.
من بينها، تأكيد القوة هو ما نستخدمه في EggJS، وقد ذكرته أيضًا منذ عدة سنوات: "ربما أفضل مكتبة JS Assert - ملابس الإمبراطور الجديدة".
const Accept = require('power-assert');
وصف ('اختبار/showcase.test.js'، () => {
const arr = [1, 2, 3];
it('تأكيد القوة', () => {
تأكيد(arr[1] === 10);
});
});
//الإخراج:
4) اختبار/showcase.test.js تأكيد الطاقة:
خطأ في التأكيد: # test/showcase.test.js:6
تأكيد (arr[1] === 10)
|
|.2 كاذبة
[1،2،3]
[الرقم] 10
=> 10
[رقم] آر[1]
=> 2ملاحظة: إذا كنت تريد التحقق من محتوى الملف، فقد كتبت أيضًا ملف تأكيد، فمرحبًا بتجربته.
نظرًا لأنه اختبار وحدة، فمن الضروري غالبًا محاكاة البيئة أو الاستجابات النهائية.
sinonjs ليس سيئًا ويدعم النماذج والنماذج وما إلى ذلك. لدى jest أيضًا مكتبة وهمية خاصة بها.
إذا كان اختبار HTTP، فإن nock قوي جدًا ويمكن أن يساعدك في الاستهزاء باستجابة الخادم.
نوك('http://www.example.com')
.post('/تسجيل الدخول', 'اسم المستخدم=pgte&password=123456')
.رد (200، {المعرف: '123ABC' })ومع ذلك، تحتوي مكتبة طلبات undici الرسمية لـ Node.js أيضًا على إمكانات Mock مدمجة.
هناك أيضًا مصطلح يسمى اللقطة، ويعني تفريغ البيانات أثناء التشغيل واستخدامها مباشرة كبيانات وهمية للاختبار التالي، مما قد يؤدي إلى تحسين كفاءة كتابة الاختبارات إلى حد ما.
لاختبار سيناريوهات خادم HTTP، لا غنى عن مكتبة الاختبار الفائق.
وصف ("الحصول على / المستخدمين"، وظيفة () {
it('يستجيب مع json'، وظيفة غير متزامنة () {
طلب العودة (التطبيق)
.get('/المستخدمين')
.set('قبول'، 'application/json')
.expect("نوع المحتوى"، /json/)
توقع(200)
.ثم(الاستجابة => {
تأكيد(response.body.email, '[email protected]');
});
});
});أحد سيناريوهات الاستخدام الرئيسية لـ Node.js هو سطر الأوامر CLI، مثل Webpack وBabel، والتي تتطلب أيضًا اختبار الوحدة.
وهذا ما نوصي به:
GitHub - وحدات العقدة/clet: اختبار سطر الأوامر E2E
GitHub - وحدات العقدة/القهوة: اختبار سطر الأوامر على Node.js
استيراد {عداء، مفاتيح} من 'clet'؛
it('يجب أن يعمل مع النمطي', async () => { انتظار runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // انتظر stdout، ثم قم بالرد .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // التحقق من صحة stdout .notStderr(/ npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // التحقق من صحة الملف });
بالنسبة للزحف الخفيف للصفحات، يمكنك استخدام HTTP مباشرةً لطلب المكتبة.
لمحاكاة التنفيذ الفعلي للمتصفح، تم استخدام السيلينيوم و phantomjs في الأيام الأولى.
ثم أصدرت Google رسميًا محرك الدمى، نظرًا لتراكم Chromium واستنادًا إلى بروتوكول devtools، سرعان ما أصبح شائعًا وقتل الأولين. وتشمل المنتجات المنافسة المماثلة الكاتب المسرحي والسرو.
بالمناسبة، سأقوم بتنزيل macacajs، وهي أداة اختبار متعددة المحطات، بالإضافة إلى المتصفحات، فهي تدعم أيضًا اختبار تطبيقات الأجهزة المحمولة وتطبيقات سطح المكتب، وهي مفتوحة المصدر من قبل مهندسين من فريق Yuque.
عندما نكتب مصدرًا مفتوحًا، غالبًا ما نحتاج إلى خدمات التكامل المستمر الآلي لمساعدتنا في الاختبار.
من بين اللاعبين في هذا المجال: Travis، وAppveyor، وGitHub Actions، وما إلى ذلك.
الآن أستخدم GitHub Actions بشكل أساسي، ومستوى التكامل رائع جدًا.
ليس هناك شك في أن اختبار الوحدة مهم جدًا، فهو قدرة ضرورية وجودة احترافية للمبرمج المؤهل.
بالطبع، نحن لسنا متعصبين للتغطية بنسبة 100%، وفي كثير من الحالات، نحتاج إلى متابعة نقطة التوازن لعائد الاستثمار.
أولاً، اسمحوا لي أن أصحح وجهة نظر الوافد الجديد: هل اختبارات وحدة الكتابة مضيعة للوقت؟
في الواقع، كتابة اختبارات الوحدة ستوفر عليك الوقت. والسبب في هذا الرأي غير البديهي هو أن شروط المقارنة غالبًا ما تكون غير موضوعية. نحن بحاجة إلى النظر في تكلفة الانحدار بعد تعديل الكود مرتين تحت نفس متطلبات الجودة.
للحصول على مقارنة عادلة، بالإضافة إلى النظر في "الوقت المناسب لكتابة اختبار واحد"، فإن ما يتم التغاضي عنه بسهولة هو "الوقت المناسب لإجراء اختبار الانحدار بعد كل تعديل للكود":
عند كتابة اختبار واحد، قم بإنشاء نماذج فرعية مختلفة في المرحلة المبكرة، ويكون وقت اختبار الانحدار هو مجرد الكتابة على لوحة المفاتيح؛
بدون كتابة اختبار واحد، تحتاج إلى تحديث الكود في التطبيق، ثم محاكاة المواقف المختلفة للاختبار يدويًا، مثل فتح المتصفح والنقر على العديد من الأماكن المختلفة.
من الواضح في لمحة أن مدى استهلاك هذين الأمرين للوقت واضح.
إنه ليس أكثر من استثمار أولي + تكلفة صيانة + التركيز على جودة العائد. كل شركة لها مقياسها الخاص عند اتخاذ القرارات بعد وزنها.
بالطبع، العديد من السيناريوهات التي ذكرتها هي مكتبات إطار العمل (بما في ذلك الواجهة الأمامية وNode.js)، والتطبيقات من جانب الخادم، وأدوات سطر الأوامر، وما إلى ذلك. وصحيح أن بعض تطبيقات الواجهة الأمامية التي تحتوي على تغيير كبير في عرض واجهة المستخدم أو التحميل والتفريغ السريع بالنسبة لصفحة النشاط، فإن تكلفة صيانة الاختبار الفردي المقابلة مرتفعة جدًا بالفعل، ومن المعقول في هذا الوقت التخلي عن الاختبارات الفردية لبعض الفروع غير الأساسية بناءً على عائد الاستثمار.
ولكن يجب أن نفهم أن هذا هو الملاذ الأخير، حيث يمكننا تقليل تكلفة صيانة اختبار الوحدة من خلال وسائل مختلفة، لكن لا يمكننا الادعاء بأن اختبار الوحدة عديم الفائدة.
يوجد أيضًا اختبار انحدار شبه آلي في حقل الواجهة الأمامية، والذي يعتمد على الفرق لأتمتة المقارنة ثم تذكير المالك بالانتباه إلى تأثير التغييرات. وهذا يشبه تمامًا مكتبات الأدوات المذكورة أعلاه، والتي توجد جميعها هنا للمساعدة في تقليل تكلفة كتابة اختبارات فردية.
وهذا أيضًا رأي خاطئ، يجب أن تتم كتابة اختبارات الوحدة بواسطة المبرمجين أنفسهم ، لأنها كود خاص بك، ويجب أن تكون مسؤولاً عنها، وهذا نوع من الاحتراف. يحتاج أي فريق لديه القليل من التقييس إلى اختبار CI عند إرسال التعليمات البرمجية، وإلا فلن يكون هناك تعاون في مراجعة التعليمات البرمجية للجودة.
طلاب الاختبار مسؤولون عن العمل على مستوى أكبر مثل اختبار التكامل، واختبار الانحدار، والاختبار الشامل .
تقسيم العمل مختلف، لذا يرجى عدم إلقاء اللوم على الآخرين.
يعد اختبار الوحدة أمرًا ضروريًا للغاية. إن كتابة اختبارات الوحدة هي الجودة المهنية الأساسية للمبرمجين. يمكنك الكتابة قدر الإمكان في السيناريوهات الفردية، بناءً على عائد الاستثمار.