كيفية الحصول على أفضل في الاختبار مع تطوير يحركها الاختبار

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

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

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

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

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

بعد ذلك ، قد تفكر في "أيا كان الأمر ، لم أكن أعرف كيف أختار الشفرة. سأترك هذا التطبيق بدون تغيير وسأنتقل إلى شيء آخر. "

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

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

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

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

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

وحدة التجارب

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

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

فيما يلي مزايا اختبار الوحدة:

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

تطوير يحركها الاختبار (TDD)

لفهم واستخدام التطوير القائم على الاختبار ، ما عليك سوى تطبيق هاتين القاعدتين:

  • اكتب اختبارًا يفشل قبل كتابة الكود.
  • بعد ذلك ، لا تكتب رمزًا أكثر مما هو كافٍ لاجتياز الاختبار الفاشل.

عندما نستخدم TDD ، نتحدث أيضًا عن دورة Red / Green / Refactor.

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

يبدو نظريا؟ لا تقلق سوف تفهم من خلال الممارسة.

هيكلة ملف الاختبار

توفر Jest وظائف لتنظيم اختباراتك:

  • صف: يستخدم لتجميع اختباراتك ووصف سلوك وظيفتك / الوحدة / الصف. يستغرق اثنين من المعلمات. أول واحد هو سلسلة تصف مجموعتك. الثانية هي وظيفة رد الاتصال التي لديك حالات الاختبار الخاصة بك أو وظائف هوك.
  • ذلك أو الاختبار: حالة الاختبار الخاصة بك ، وهذا يعني اختبار وحدتك. المعلمات هي بالضبط نفس الوصف. يجب أن يكون وصفي. إن تسمية الاختبار متروك لك ولكن من المعتاد أن نبدأ بها بـ "should".
  • beforeAll (afterAll): وظيفة ربط تعمل قبل (وبعد) جميع الاختبارات. يستغرق معلمة واحدة وهي الوظيفة التي ستقوم بتشغيلها قبل (وبعد) جميع الاختبارات.
  • beforeEach (afterEach): وظيفة ربط تعمل قبل (وبعد) كل اختبار. يستغرق معلمة واحدة وهي الوظيفة التي ستقوم بتشغيلها قبل (وبعد) كل اختبار.

يجب أن تعرف أيضًا ما يلي قبل كتابة أي اختبار:

  • يمكنك تخطي الاختبار عن طريق استخدام .skip on description و: it.skip (...) أو description.skip (...). باستخدام .skip ، فأنت تخبر Jest بتجاهل الاختبار أو المجموعة.
  • يمكنك تحديد الاختبارات التي ترغب في تشغيلها بالضبط. يكون هذا مفيدًا إذا كان لديك الكثير من الاختبارات وترغب في التركيز على اختبار واحد فقط أو إذا كنت ترغب في "تصحيح" اختباراتك.

إعداد Jest

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

كشرط مسبق ، تحتاج فقط Node.js و npm أو الغزل. تأكد من استخدام أحدث إصدار من Node.js لأننا سنستخدم ES6. إنشاء دليل جديد وتهيئته.

mkdir test-example && cd test-example
npm init -y
# أو
غزل الحرف الأول- y

يجيب نعم على جميع أسئلة npm أو الغزل. يجب أن يكون قد تم إنشاء ملف package.json أساسي للغاية.

ثم أضف Jest إلى تبعيات المطور الخاصة بك:

إضافة الغزل مزاح - ديف

أخيرًا أضف النص التالي إلى package.json:

"نصوص": {
  "اختبار": "مزاح"
}

سيتم تشغيل اختبار الغزل ملفات الاختبارات الخاصة بك في الدليل الخاص بك. بشكل افتراضي ، يتعرف Jest على الملفات الموجودة داخل دليل يسمى __tests__ أو الملفات التي تنتهي إما بـ. spec.js أو .test.js.

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

Matchers

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

نتوقع (المدخلات) .matcher (المخرجات)

Jest لديه الكثير من المطابقات ، لذا إليك أكثرها شيوعًا:

  • toBe: يقارن المساواة الصارمة (===).
توقع (1 + 1). إلى (2)
واسمحوا الاختبارات areEssential = صحيح
نتوقع (testAreEssential) .toBe (صحيح)
  • toEqual: يقارن القيم بين متغيرين أو صفائف أو كائنات.
دع arr = [1 ، 2]
arr.push (3)
توقع (arr). إلى إجمالي ([1 ، 2 ، 3])
دع x = 1
س ++
نتوقع (خ) .toEqual (2)
  • toBeTruthy (toBeFalsy): يوضح ما إذا كانت القيمة صحيحة (false).
نتوقع (خالية) .toBeFalsy ()
تتوقع (غير معروف) .toBeFalsy ()
نتوقع (كاذبة) .toBeFalsy ()
توقع ("Hello world"). toBeTruthy ()
توقع ({foo: 'bar'}). toBeTruthy ()
  • لا: يجب وضعه أمام أحد المطابقين وإرجاع عكس نتيجة المطابق.
نتوقع (خالية) .not.toBeTruthy ()
/ / كما هو متوقع (فارغ). toBeFalsy ()
نتوقع ([1]). not.toEqual ([2])
  • toContain: يتحقق مما إذا كان الصفيف يحتوي على العنصر في المعلمة.
توقع (['Apple' ، 'Banana' ، 'Strawberry']). toContain ('Apple')
  • toThrow: بالتحقق مما إذا كانت الدالة تلقي خطأ
وظيفة الاتصال () {
  رمي اتصال جديد ()
}
نتوقع (الاتصال) .toThrow (ConnectionError)

هذه ليست فقط المباريات. يمكنك أن تجد جميع المباريات Jest هنا.

الاختبارات الأولى

الآن ، سنقوم بكتابة أول اختبار لنا ولعبنا مع وظائفنا. أولاً ، قم بإنشاء ملف باسم example.spec.js في الدليل الخاص بك ولصق المحتوى التالي:

صف ("مثال" ، () => {
  beforeAll (() => {
    console.log ('التشغيل قبل كل الاختبارات')
  })
  afterAll (() => {
    console.log ('التشغيل بعد كل الاختبارات')
  })
  قبل كل (() => {
    console.log ("التشغيل قبل كل اختبار")
  })
  afterEach (() => {
    console.log ('التشغيل بعد كل اختبار')
  })
  هو ('يجب أن يفعل شيئًا' ، () => {
    console.log ("الاختبار الأول")
  })
  (يجب أن تفعل شيئًا آخر) ، () => {
    console.log ('الاختبار الثاني')
  })
})

لاحظ أننا لسنا بحاجة إلى استيراد جميع الوظائف التي نستخدمها. يتم توفيرها بالفعل بواسطة Jest.

تشغيل اختبار الغزل:

استكشاف وظائف الاختبار المختلفة

نظرًا لعدم وجود تأكيدات في اختباراتك ، فسوف تمر فقط. هل شاهدت عبارات console.log المختلفة؟ يجب أن تفهم بشكل أفضل كيف تعمل وظائف الخطاف وحالات الاختبار الآن.

الآن ، أزل كل وظائف الخطاف وأضف ملف .skip في الاختبار الأول:

صف ("مثال" ، () => {
  it.skip ('يجب أن تفعل شيئًا' ، () => {
    console.log ("الاختبار الأول")
  })
  (يجب أن تفعل شيئًا آخر) ، () => {
    console.log ('الاختبار الثاني')
  })
})

تشغيل اختبار الغزل مرة أخرى:

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

أضف الآن اختبارًا ثالثًا إلى مجموعة الاختبار الخاصة بك واستخدمه.

صف ("مثال" ، () => {
  هو ('يجب أن يفعل شيئًا' ، () => {
    console.log ("الاختبار الأول")
  })
  (يجب أن تفعل شيئًا آخر) ، () => {
    console.log ('الاختبار الثاني')
  })
  it.only ('يجب أن تفعل ذلك' ، () => {
    console.log ('الاختبار الثالث')
  })
})

تشغيل اختبار الغزل مرة أخرى:

مرة أخرى ، منطقي. أنت تخبر Jest بإجراء الاختبار الثالث فقط. لذلك ترى فقط الاختبار الثالث في وحدة التحكم.

اختبار كومة مع تطوير يحركها الاختبار

لا مزيد من النظرية. الوقت لممارسة.

في ما يلي ، سنعمل على تنفيذ مكدس بسيط في جافا سكريبت مع تطوير يحركه الاختبار.

كتذكير ، المكدس هو بنية بيانات ، وبشكل أكثر دقة بنية LIFO: Last In ، First Out. هناك ثلاث عمليات رئيسية لتنفيذها على مكدس:

  • دفع: يدفع عنصر في الجزء العلوي من المكدس.
  • pop: يزيل العنصر الموجود في أعلى الرصة.
  • نظرة خاطفة: إرجاع العنصر الأخير في الجزء العلوي من المكدس.

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

  • العناصر: عناصر المكدس. سنستخدم صفيفًا لتنفيذ الحزمة.
  • القدرة: قدرة المكدس.
  • isEmpty (): يتم إرجاع true إذا كانت المكدس فارغة ، false خطأ.
  • isFull (): يتم إرجاع true إذا وصلت المكدس إلى الحد الأقصى لسعته ، أي عندما لا يمكنك دفع عنصر آخر. إرجاع كاذبة خلاف ذلك.
  • دفع (عنصر): يدفع عنصر على المكدس. إرجاع ممتلئ إذا كانت المكدس ممتلئة ، يتم دفع العنصر بخلاف ذلك.
  • pop (): يزيل العنصر الأخير من المكدس. إرجاع فارغة إذا كان المكدس فارغًا ، يكون العنصر برزت على خلاف ذلك.
  • peek (): إرجاع العنصر في الجزء العلوي من بنية تخزين العناصر (تم دفع العنصر الأخير بعد ذلك). إرجاع فارغة إذا كانت المكدس فارغة ، تُرجع العنصر بخلاف ذلك.

سنقوم بإنشاء ملفين stack.js و stack.spec.js. لقد استخدمت امتداد .spec.js لأنني اعتدت عليه ولكنك حر في استخدامه .test.js أو أعطيه اسمًا آخر ووضعه تحت __test__.

أثناء قيامنا بالتطوير القائم على الاختبار ، دعنا نكتب الاختبار الفاشل. سنختبر المنشئ أولاً. لاختبار ملفك ، تحتاج إلى استيراد ملف مكدس:

const المكدس = تتطلب ('./ المكدس')

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

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

صف ('المكدس' ، () => {
})

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

هو ('يجب أن يبني المكدس بسعة معينة' ، () => {
  دع المكدس = مكدس جديد (3)
  نتوقع (stack.items) .toEqual ([])
  نتوقع (stack.capacity) .toBe (3)
})

لاحظ أننا نستخدم toEqual وليس toBe for stack.items لأنهم لا يشيرون إلى نفس الصفيف. لذلك نحن بحاجة إلى مقارنة قيمهم فقط.

الآن ، قم بتشغيل اختبار الغزل stack.spec.js. نقوم بتشغيل Jest على ملف معين لأننا لا نريد أن نتعرض للتلوث من خلال الاختبارات الأخرى. هذه هي النتيجة:

المكدس ليس منشئ. بالتاكيد. ما زلنا لم ننشئ فئة المكدس الخاصة بنا وقدمناها مُنشئًا.

في stack.js ، أنشئ فصلك الدراسي ومنشئًا وقم بتصدير الفصل:

الطبقة المكدس {
  البناء() {
  }
}
module.exports = المكدس

قم بإجراء الاختبار مرة أخرى:

نظرًا لأننا لم نقم بتعيين عناصر في المُنشئ ، فقد توقع Jest أن تكون العناصر الموجودة في المصفوفة متساوية [] ولكنها لم تحدد. يجب عليك تهيئة العناصر ثم:

البناء() {
  this.items = []
}

إذا قمت بإجراء الاختبار مرة أخرى ، فسوف تحصل على نفس النوع من الخطأ فيما يتعلق بالسعة ، لذلك يتعين عليك ضبط السعة أيضًا:

المنشئ (القدرة) {
  this.items = []
  this.capacity = القدرة
}

تشغيل اختبارنا:

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

فارغ

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

("يجب أن يكون لها وظيفة isEmpty والتي ترجع صواب إذا كانت المكدس فارغة وخاطئة على خلاف ذلك" ، () => {
  دع المكدس = مكدس جديد (3)
  نتوقع (stack.isEmpty ()). توبي (صحيح)
  stack.items.push (2)
  نتوقع (stack.isEmpty ()). توبي (كاذبة)
})

إذا قمت بإجراء الاختبار ، فيجب أن تحصل على الخطأ التالي:

TypeError: stack.isEmpty ليست دالة

لحل هذه المشكلة ، سنحتاج إلى إنشاء فارغ داخل فئة المكدس:

فارغ () {
}

إذا قمت بإجراء الاختبار ، يجب أن تحصل على خطأ آخر:

المتوقع: صحيح
تلقى: غير محدد

من المنطقي. لا شيء يضاف داخلها. تكدس فارغ إذا لم يكن هناك عناصر فيه:

فارغ () {
  إرجاع this.items.length === 0
}

ممتلئ

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

إدفع

نحتاج إلى اختبار ثلاثة أشياء مختلفة هنا:

  • يجب إضافة عنصر جديد أعلى المكدس.
  • إرجاع الإرجاع "الكامل" إذا كان المكدس ممتلئًا.
  • يجب أن يتم إرجاع العنصر الذي تم دفعه مؤخرًا.

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

صف ('Stack.push'، () => {
  
})

إضافة عنصر

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

صف ('Stack.push'، () => {
  ("يجب إضافة عنصر جديد أعلى المكدس" ، () => {
    دع المكدس = مكدس جديد (3)
    stack.push (2)
    توقع (stack.items [stack.items.length - 1]). toBe (2)
  })
})

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

دفع (عنصر) {
 this.items.push (عنصر)
}

الاختبارات تمر مرة أخرى. هل لاحظت شيئا؟ نحتفظ بنسخ هذا السطر:

دع المكدس = مكدس جديد (3)

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

اسمحوا كومة
قبل كل (() => {
 كومة = كومة جديدة (3)
})

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

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

afterEach (() => {
 stack.items = []
})

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

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

const المكدس = تتطلب ('./ المكدس')
صف ('المكدس' ، () => {
  اسمحوا كومة
  قبل كل (() => {
    كومة = كومة جديدة (3)
  })
  هو ('يجب أن يبني المكدس بسعة معينة' ، () => {
    نتوقع (stack.items) .toEqual ([])
    نتوقع (stack.capacity) .toBe (3)
  })
  ("يجب أن يكون لها وظيفة isEmpty والتي ترجع صواب إذا كانت المكدس فارغة وخاطئة على خلاف ذلك" ، () => {
    stack.items.push (2)
    نتوقع (stack.isEmpty ()). توبي (كاذبة)
  })
  صف ('Stack.push'، () => {
    ("يجب إضافة عنصر جديد أعلى المكدس" ، () => {
      stack.push (2)
      توقع (stack.items [stack.items.length - 1]). toBe (2)
    })
  })
})

اختبار القيمة التي تم إرجاعها

هنا هو الاختبار:

هو ('يجب إرجاع العنصر الجديد المدفوع في الجزء العلوي من المكدس' ، () => {
  دع elementPushed = stack.push (2)
  نتوقع (elementPushed) .toBe (2)
})

عند إجراء الاختبار ، تحصل على:

المتوقع: 2
تلقى: غير محدد

في الواقع. لا شيء عاد داخل دفع! نحتاج لإصلاح ذلك:

دفع (عنصر) {
  this.items.push (عنصر)
  عودة العنصر
}

إرجاع ممتلئ إذا كانت المكدس ممتلئة

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

it ('يجب أن يعود بالكامل إذا حاول المرء الدفع في أعلى الرصة بينما يكون ممتلئ' ، () => {
  stack.items = [1 ، 2 ، 3]
  اسمح للعنصر = stack.push (4)
  توقع (stack.items [stack.items.length - 1]). toBe (3)
  نتوقع (عنصر) .toBe ( 'الكامل')
})

يجب أن تحصل على هذا الخطأ عند تشغيل الاختبار:

المتوقع: 3
تلقى: 4

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

دفع (عنصر) {
  إذا كان (this.isFull ()) {
    إرجاع "كامل"
  }
  
  this.items.push (عنصر)
  عودة العنصر
}

الاختبارات تمر الآن. لقد انتهينا من الدفع!

ممارسة: البوب ​​ونظرة خاطفة

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

بعض التلميحات:

  • يشبه البوب ​​حقًا الاختبار الحكيم.
  • نظرة خاطفة يشبه حقًا اختبار البوب ​​أيضًا!
  • حتى الآن ، لم نقم بإعادة تشكيل الشفرة ، لأنه لم تكن هناك حاجة لإعادة تشكيلها. في هذه الوظائف ، قد يكون هناك طريقة لإعادة تفعيل كودك بعد كتابة الاختبارات وجعلها تمر. لا تقلق إذا عدلت الشفرة ، فإن الاختبارات موجودة لإعلامك بالخطأ.

لا تنظر إلى الحل أدناه دون المحاولة أولاً. الطريقة الوحيدة للتقدم هي تجربة الأشياء وتجريبها وبناءها.

المحلول

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

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

إذا كان (this.isEmpty ()) {
  إرجاع "فارغ"
}
إرجاع this.items.pop ()

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

قم بإجراء اختباراتك آخر مرة:

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

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

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

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