Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Rspec
Code

اختبار RSpec للمبتدئين ، الجزء 1

by
Length:LongLanguages:
This post is part of a series called RSpec Testing for Beginners.
RSpec Testing for Beginners, Part 2

Arabic (العربية/عربي) translation by ansgaradh (you can also view the original English article)

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

المواضيع

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

ما هي النقطة؟

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

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

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

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

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

فوائد ومثل

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

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

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

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

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

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

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

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

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

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

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

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

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

ابدء

طرفيه

-T يتيح لك تخطي وحدة الاختبار ، وإطار الاختبار الذي يأتي مع القضبان.

Gemfile

طرفيه

بعد ذلك نحتاج إلى تشغيل مولد يأتي مع RSpec:

طرفيه

انتاجيه

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

  • spec_helper.rb هي للمواصفات التي لا تعتمد على Rails.
  • rails_helper.rb ، من ناحية أخرى ، للمواصفات التي تعتمد عليها.

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

طرفيه

انتاجيه

لن تقوم Rails فقط بإنشاء ملفات _spec.rb المقترنة لك ، بل ستتطلب المواصفات الخاصة بك أيضًا "rails_helper" بشكل افتراضي أعلى ملفات المواصفات الخاصة بك. هذا يعني أنك على استعداد للذهاب ، على الفور.

spec/models/dummy_model_spec.rb

لذلك مع هذا الإعداد ، يمكنك اختبار تطبيق Rails ، نماذجك على سبيل المثال ، ولن يتم الخلط بين RSpec حول فئات النماذج المستخدمة في Rails. وهذا ضروري لتطلب كلما كنت بحاجة إلى أشياء مثل ActiveRecord ، ApplicationController وهكذا. لذلك هذا هو السيناريو العادي ، وبالتالي يجب أن يكون اختيارك الأول المنطقي كمبتدئ.

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

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

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

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

باستخدام مولد لإنشاء نموذج وهمي قدمت لنا بالفعل المواصفات / نماذج / dummy_model_spec.rb. ليس سيئا! شيء واحد يجب القيام به قبل الاختبارات جاهزة:

طرفيه

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

طرفيه

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

الإنتاجيه

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

الانتاجيه

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

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

الطرفيه

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

الطرفيه

من السهل على هذا!

بناء الجملة الأساسي

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

  • وصف

سيكون هذا هو الخبز والزبدة لأنها تنظم المواصفات الخاصة بك. يمكنك الإشارة إلى السلاسل أو الصفوف نفسها:

بعض المواصفات

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

بعض المواصفات

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

بعض المواصفات

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

  • هذا

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

بعض المواصفات

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

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

  •  توقع()

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

بعض المواصفات

تتوقع () هو بناء الجملة التوكيد "الجديد" من RSpec. سابقا كنا تستخدم should بدلا من ذلك. قصة مختلفة ، لكني أردت أن أذكر ذلك في حال واجهتك. تتوقع () تتوقع أن توفره مع كائن وممارسة أي طريقة تحت الاختبار على ذلك. أخيرا ، تكتب النتيجة المؤكدة على الجانب الأيمن.

لديك خيار الانتقال إلى المسار الإيجابي أو السلبي باستخدام .qq أو .not_to eq على سبيل المثال (eq اختصار للمسايرة بالطبع). يمكنك دائمًا تشغيل المنطق - أيًا كان يناسب احتياجاتك. دعنا نجري هذا الاختبار الباهت ونركز على المخرجات التي حصلنا عليها نتيجة لإعداد الاختبار لدينا:

الطرفيه

الإنتاجيه

يقرأ جميلة ، أليس كذلك؟ ** "Agent # favorite_gadget بإرجاع عنصر واحد ، والأداة المفضلة للوكيل" ** يخبرك بكل ما تحتاج إلى معرفته:

  • الطبقه المعنيه
  • الطريقة تحت الاختبار
  • النتيجة المتوقعة

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

بعض المواصفات

الإنتاجيه

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

أربع مراحل من الاختبار

توصى أفضل الممارسات في الاختبار بأننا نؤلف اختباراتنا في أربع مراحل متميزة:

  • اعداد الاختبار
  • ممارسة الاختبار
  • التحقق من الاختبار
  • اختبار teardown

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

اقامة

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

تمرن

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

التحقق

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

تمزيق

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

بعض المواصفات

كما ترون ، في هذا المثال فصلنا التمرين والتحقق من مراحل بشكل واضح من بعضنا البعض ، بينما في الأمثلة الوهمية الأخرى المذكورة أعلاه ، توقع (agent.favorite_gadget). إلى eq 'Walther PKK ، قمنا بخلط كلا المرحلتين معًا. كلاهما سيناريوهات صالحة ولها مكانها. أيضا ، تساعد الخطوط الجديدة لفصل بصري كيف يتم تنظيم الاختبار.

الشيء الصعب حول الاختبار

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

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

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

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

افكار اخيرة

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

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

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.