اختبارات تطبيقات ريلز

يشمل هذا الدليل الآليّات المدمجة في ريلز لإجراء الاختبارت على التطبيقات. بعد قراءة هذا الدليل، ستتعلم:

• الاصطلاح المتعلّق باختبارات ريلز.
• كيفيّة كتابة كلٍّ من اختبارات الوحدة، الاختبارات الوظيفيّة، والاختبارات التكامليّة لتطبيقات ريلز.
• وغيرها من الطرق والإضافات الخاصّة بالاختبارات.

ما الهدف من كتابة اختبارات لتطبيقات ريلز؟

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

مقدمة إلى الاختبارات

كان دعم الاختبارات من اللبنات الأساسيّة لريلز منذ البداية، و لم يكن أبدًا وليد لحظةٍ من الإلهام أو محاولةٍ لمجاراة الرّكب.

يهيئ ريلز للاختبارات من البداية

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

$ ls -F test
controllers/           helpers/               mailers/               system/                test_helper.rb
fixtures/              integration/           models/                application_system_test_case.rb

من المفترض أن تحوي المجلّدات ‏helpers، و ‏‏mailers‏، و models الاختبارات الخاصّة بالدّوال المساعدة للواجهة، وإجراء المراسلة، والنّماذج على التّوالي. بينما يحتوي المجلّد controllers  على الاختبارات الخاصّة بوحدات التحكّم، ومسارات التوجيه، والواجهات. أما المجلّد integration، فإنّه يحوي الاختبارات الخاصّة بالتفاعلات بين وحدات التحكّم.

يحتوي المجلد system على اختبارات النّظام التي تستعمل عند الاختبارات الشّاملة على المتصفّح. تمكّنك اختبارات النّظام من تجربة تطبيقك على الوجه الذي يُفترض بالمستخدمين أن يجرّبوه، كما تمكّنك أيضًا من اختبار JavaScript. هذا بالإضافة إلى أنّها تَرِث من Capybara.

تمثّل تحضيرات الاختبار (Fixtures) طريقةً لتنظيم بيانات الاختبار وتقع في المجلّد fixtures، ويُنشَأ المجلّد jobs حال تولُّيد أوّل اختبار تابع له. يحوي الملفّ test_helper.rb الضّبط الافتراضيّ للاختبارات ككُلّ، بينما يحوي الملفّ application_system_test_case.rb الضّبط الافتراضيّ لاختبارات النّظام.

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

لكلّ تطبيق ريلز ثلاث بيئات افتراضيّة: بيئة التطوير، وبيئة الاختبار، وبيئة الإنتاج. يمكن ضبط كلّ بيئة من هذه البيئات على نحوٍ مماثل. في حالتنا هذه، يمكننا ضبط بيئة الاختبار من خلال تغيير الخيارات الموجودة في الملفّ config/environments/test.rb.

ملاحظة: تُنفَّذ اختباراتك في البيئة RAILS_ENV=test.  

ريلز مع Minitest

إن كنت تذكر، استعملنا الأمر rails generate model في دليل البدء مع ريلز. أنشأنا حينها أوّل نموذج لنا، ومن الأمور التي أنشأها أيضًا هو بذور الاختبار (test stubs) في المجلد test:

$ bin/rails generate model article title:string body:text
...
create  app/models/article.rb
create  test/models/article_test.rb
create  test/fixtures/articles.yml
...

تبدو بذرة الاختبار الافتراضيّة في الملفّ test/models/article_test.rb كالتالي:

require 'test_helper'
 
class ArticleTest < ActiveSupport::TestCase
  # test "the truth" do
  #   assert true
  # end
end

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

require 'test_helper'

يؤديّ تضمين الملفّ test_helper.rb إلى تحميل الضّبط الافتراضيّ لإجراء الاختبارات. من الآن فصاعدًا، سنضمّن هذا الملفّ عند كلّ الاختبارات التي نكتبها، وبهذا تكون كلّ التوابع التي نضيفها لهذا الملفّ متاحة لكلّ الاختبارات.

class ArticleTest < ActiveSupport::TestCase

يعرّف الصّنف ArticleTest حالة اختبار (test case) لأنها ترث من ActiveSupport::TestCase. وبالتالي، تملك ArticleTest كل التوابع التي تتيحها ActiveSupport::TestCase. سنرى لاحقًا في هذا الدليل بعض التوابع التي تمنحنا إيّاها.

التّوابع المعرّفة في صنفٍ يرث من Minitest::Test (الذي هو صنف أبٍ لـ ActiveSupport::TestCase) والتي تبدأ بـ test_‎ (بالأحرف الصغيرة) يُطلق عليها ببساطة "اختبار". وبهذا، التوابع المعرّفة كـ test_password و test_valid_password هي أسماء اختبارات جائزة وتشتغل آليًّا عند إجراء حالة الاختبار.

يمكن لريلز أيضًا إضافة تابع اختبار عن طريق تقديم اسمٍ للاختبار وكتلة، ليولّد بذلك اختبار Minitest::Unit عاديًّا بأسماء توابع مسبوقة بـ test_‎. وبهذا ليس عليك أن تنشغل بتسمية التوابع وتكتفي بكتابة شيءٍ من هذا القبيل:

test "the truth" do
  assert true
end

وهو تقريبًا كما لو كتبته بهذا الشكل:

def test_the_truth
  assert true
end

مع أنّه يبقى بإمكانك اتّباع الطريقة الاعتياديّة لتعريف التوابع، لكنّ استعمال الماكرو test كما سبق يضفي المزيد من الوضوح على أسماء الاختبارات.

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

بعد هذا، لنُلقِ نظرة على تحقّقنا الأوّل:

assert true

التحقّق هو سطر شيفرة يعمل على تقدير صحّة كائن (أو تعبير) ما. من أمثلة ذلك:

• هل هذه القيمة تساوي تلك القيمة؟
• هل هذا الكائن هو كائن عدمي nil؟
• هل سيولّد سطر الشيفرة هذا استثتاءً؟
• هل تفوق كلمة مرور المستخدم هذه عن 5 أحرف؟

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

أول اختبار فاشل لك

للاطلاع على كيفيّة التبليغ عن فشل الاختبار، بإمكانك إضافة اختبار فاشل لحالة اختبار في article_test.rb.

test "should not save article without title" do
  article = Article.new
  assert_not article.save
end

لِنُجرِ الاختبار الذي أضفناه للتوّ (حيث أنّ السطر الذي عٌرّف فيه الاختبار هو السادس).

$ bin/rails test test/models/article_test.rb:6
Run options: --seed 44656
 
# Running:
 
F
 
Failure:
ArticleTest#test_should_not_save_article_without_title [/path/to/blog/test/models/article_test.rb:6]:
Expected true to be nil or false
 
 
bin/rails test test/models/article_test.rb:6
 
 
 
Finished in 0.023918s, 41.8090 runs/s, 41.8090 assertions/s.
 
1 runs, 1 assertions, 1 failures, 0 errors, 0 skips

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

test "should not save article without title" do
  article = Article.new
  assert_not article.save, "Saved the article without a title"
end

يُظهر إجراء الاختبار هذا رسالةً ألطف من تلك التي يظهرها المتحقّق:

Failure:
ArticleTest#test_should_not_save_article_without_title [/path/to/blog/test/models/article_test.rb:6]:
Saved the article without a title

والآن حتى نجعل هذا الاختبار ناجحًا، يمكننا إضافة مصادقة على مستوى النموذج (model level validation) للحقل title:

class Article < ApplicationRecord
  validates :title, presence: true
end

من المفترض أن ينجح الاختبار الآن. لنتأكد من ذلك بإجراء الاختبار ثانيةً:

$ bin/rails test test/models/article_test.rb:6
Run options: --seed 31252
 
# Running:
 
.
 
Finished in 0.027476s, 36.3952 runs/s, 36.3952 assertions/s.
 
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips

لو لاحظت ذلك، كتبنا في البداية اختبارًا ليفشل من أجل وظيفة مرجوّة، ثم كتبنا بعدها شيفرة لتضيف هذه الوظيفة، وفي النهاية تأكّدنا أنّ اختبارنا قد نجح. تُسمّى هذه الطريقة في تطوير البرمجيّات "بالتطوير وفق الاختبار" (Test-Driven Development).

كيف يبدو الخطأ

لترى كيف يُبلَّغ عن الخطأ، إليك اختبارًا يحتوي على واحد:

test "should report error" do
  # غير معرف في حالة الاختبار some_undefined_variable إن
  some_undefined_variable
  assert true
end

ترى الآن المزيد من المخرجات في الطّرفية بعد إجراء هذا الاختبار:

$ bin/rails test test/models/article_test.rb
Run options: --seed 1808
 
# Running:
 
.E
 
Error:
ArticleTest#test_should_report_error:
NameError: undefined local variable or method 'some_undefined_variable' for #<ArticleTest:0x007fee3aa71798>
    test/models/article_test.rb:11:in 'block in <class:ArticleTest>'
 
 
bin/rails test test/models/article_test.rb:9
 
 
 
Finished in 0.040609s, 49.2500 runs/s, 24.6250 assertions/s.
 
2 runs, 1 assertions, 0 failures, 1 errors, 0 skips

لاحظ وجود الحرف E في المخرجات. يعبّر ذلك عن خطأ في الاختبار.

ملاحظة: يتوقف تنفيذ تابع الاختبار حالما يصادف خطأً أو فشلًا في التحقّق، وينتقل الاختبار إلى تنفيذ التابع التالي. تُنفّذ توابع الاختبار وفق ترتيب عشوائيّ. يمكن ضبط ترتيب الاختبار من خلال الخيار config.active_support.test_order.

عندما يفشل اختبار ما، يُعرَض لك التتبّع العكسيّ (backtrace) الخاصّ بهذا الاختبار. يعمل ريلز افتراضيًّا على ترشيح ذلك التتبّع العكسي، ويخرج فقط الأسطر الخاصّة بتطبيقك. يساعد هذا على إزالة التشويش الناجم عن إطار العمل، ويمكّنك من التركيز على شيفرتك. لكن في حالة ما أردت الاطلاع على التتبّع العكسيّ كاملًا يكفي أن تضيف الوسيط b- (أو backtrace--).

$ bin/rails test -b test/models/article_test.rb

إذا أردنا لهذا الاختبار أن ينجح، يمكن أن نُعدّله بأن يستعمل assert_raises بالشكل التالي:

test "should report error" do
  # غير معرف في مكان آخر في حالة الاختبار some_undefined_variable إن
  assert_raises(NameError) do
    some_undefined_variable
  end
end

لابدّ أن ينجح الاختبار الآن.

التحقّقات المتاحة

مما سبق، يفترض الآن أنك أخذت لمحةً خاطفةً عن التحقّقات المتاحة في ريلز. تٌعتبر التحقّقات بمثابة النحلات العاملة، إذ أنّها هي المسؤولة عن الفحص والتأكّد من أن كلّ شيءٍ يسير حسب ما خُطّط له.

ما يلي خلاصة من التحقّقات التي يمكن أن تستعملها مع Minitest، المكتبة الافتراضيّة التي تستعملها ريلز للاختبارات. المعامل [msg] هو سلسلة نصيّة اختياريّة يمكنك استعماله لجعل رسائل فشل الاختبار أكثر وضوحًا.

التحقّق	الغرض
assert( test, [msg] )‎	يتأكّد من أنّ قيمة test هي true.
assert_not( test, [msg] )‎	يتأكّد من أنّ قيمة test هي false.
assert_equal( expected, actual, [msg] )‎	يتأكّد من أنّ قيمة expected == actual هي true.
assert_not_equal( expected, actual, [msg] )‎	يتأكّد من أن قيمة expected != actual هي true.
assert_same( expected, actual, [msg] )‎	يتأكّد من أنّ قيمة (expected.equal?(actual هي true.
assert_not_same( expected, actual, [msg] )‎	يتأكّد من أنّ قيمة (expected.equal?(actual هي false.
assert_nil( obj, [msg] )‎	يتأكّد من أنّ قيمة obj.nil?‎ هي true.
assert_not_nil( obj, [msg] )‎	يتأكّد من أنّ قيمة obj.nil?‎ هي false.
assert_empty( obj, [msg] )‎	يتأكّد من أنّ قيمة obj هي empty?‎.
assert_not_empty( obj, [msg] )‎	يتأكّد من أنّ قيمة obj ليست empty?‎.
assert_match( regexp, string, [msg] )‎	يتأكّد من أنّ قيمة السّلسلة النصيّة string تطابق التعبير النمطيّ regexp.
assert_no_match( regexp, string, [msg] )‎	يتأكّد من أنّ قيمة السّلسلة النصيّة string لا تطابق التعبير النمطيّ regexp.
assert_includes( collection, obj, [msg] )‎	يتأكّد من أنّ obj هو ضمن collection.
assert_not_includes( collection, obj, [msg] )‎	يتأكّد من أنّ obj ليس ضمن collection.
assert_in_delta( expected, actual, [delta], [msg] )‎	يتأكّد من أنّ الفرق بين العددين actual و expected هو أقلّ من delta.
assert_not_in_delta( expected, actual, [delta], [msg] )‎	يتأكّد من أنّ الفرق بين العددين actual و expected ليس أقلّ من delta.
assert_in_epsilon ( expected, actual, [epsilon], [msg] )‎	يتأكّد من أنّ نسبة العددين actual و expected إلى بعضهما هي أقلّ من epsilon.
assert_not_in_epsilon ( expected, actual, [epsilon], [msg] )‎	يتأكّد من أنّ نسبة العددين actual و expected إلى بعضهما ليست أقلّ من epsilon.
assert_throws( symbol, [msg] ) { block }‎	يتأكّد من أنّ الكتلة block ترمي الرمز symbol.
assert_raises( exception1, exception2, ... ) { block }‎	يتأكّد من أنّ الكتلة block ترمي إحدى الاستثناءات exception1‏،‎‎‎‎‎exception2‎ ‎‏‏‎‎، ....
assert_instance_of( class, obj, [msg] )‎	يتأكّد من أنّ obj نسخة من الصّنف class.
assert_not_instance_of( class, obj, [msg] )‎	يتأكّد من أنّ obj ليس نسخة من الصّنف class.
assert_kind_of( class, obj, [msg] )‎	يتأكّد من أنّ obj نسخة من الصّنف class أو منُحدرٌ منه.
assert_not_kind_of( class, obj, [msg] )‎	يتأكّد من أنّ obj ليس نسخة من الصّنف class ولا هو منُحدرٌ منه.
assert_respond_to( obj, symbol, [msg] )‎	يتأكّد من أنّ obj يستجيب لـ symbol.
assert_not_respond_to( obj, symbol, [msg] )‎	يتأكّد من أنّ obj لا يستجيب لـ symbol.
assert_operator( obj1, operator, [obj2], [msg] )‎	يتأكّد من أنّ قيمة obj1.operator(obj2)‎ هي true.
assert_not_operator( obj1, operator, [obj2], [msg] )‎	يتأكّد من أنّ قيمة obj1.operator(obj2)‎ هي false.
assert_predicate ( obj, predicate, [msg] )‎	يتأكّد من أنّ قيمة obj.predicate‎ هي true، مثلًا: assert_predicate str, :empty?‎.
assert_not_predicate ( obj, predicate, [msg] )‎	يتأكّد من أنّ قيمة obj.predicate‎ هي false، مثلًا: assert_not_predicate str, :empty?‎.
flunk( [msg] )‎	يتأكّد من الفشل. يساعد هذا على وسم اختبارٍ لم يكتمل بعد.

ما سبق مجموعة من التحقّقات التي تدعمها minitest. للاطّلاع على القائمة الشّاملة والأحدث، يُرجى التوجّه إلى توثيق الواجهة البرمجية للمكتبة Minitest, وبالأخصّ Minitest::Assertions.

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

ملاحظة: يُعدّ إنشاء تحقّقاتك الخاصّة موضوعًا مُتقدّما لن يُتطرّق إليه في هذا الدليل.

التحقّقات الخاصّة بريلز.

يضيف ريلز عدّة تحقّقات خاصّة به لإطار عمل minitest:

التحقّق	الغرض
assert_difference(expressions, difference = 1, message = nil) {...}‎	يتحقّق من الاختلاف العددي بين القيمة المعادة للتعبير expressions وبين النتيجة المقيَّمة في الكتلة المعطاة.
assert_no_difference(expressions, message = nil, &block)‎	اختبار الناتج العددي لتقييم التعبير expressions والتأكد من عدم تغيره قبل وبعد تمريره إلى الكتلة.
assert_changes(expressions, message = nil, from:, to:, &block)‎	التحقق من تغيّر ناتج تقييم التعبير expressions بعد تمريره إلى الكتلة.
assert_no_changes(expressions, message = nil, &block)‎	التحقق من عدم تغير تقييم التعبير expressions بعد تمريره إلى الكتلة.
assert_nothing_raised { block }‎	التأكد من عدم رمي الكتلة المعطاة استثناءً.
assert_recognizes(expected_options, path, extras={}, message=nil)‎	اختبار عملية إعادة التوجيه للمسار المعطى والتأكد من أنها نُفِّذت بشكل صحيح وأن الخيارات المحللة (المعطاة في expected_options الذي هو جدول Hash) تطابق المسار. بشكل أساسي، يتأكد هذا الاختبار من تعرف ريلز مسار التوجيه المعطى عبر expected_options.
assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)‎	اختبار الخيارات المعطاة والتأكد من إمكانية استعمالها لتوليد المسار المعطى. هذا الاختبار هو عكس الاختبار assert_recognizes.  تستعمل المعاملات الإضافية لإخبار الطلب بأسماء وقيم معاملات الطلب الإضافية التي ستكون في سلسلة الاستعلام. يسمح المعامل message بتحديد رسالة خطأ مخصصة لعرضها عند فشل الاختبار.
assert_response(type, message = nil)‎	اختبار الرد (response) والتأكد من احتوائه عىل رمز حالة محدد. يمكنك أن تحدد ‎:success ليشير إلى المجال 200-299، أو ‎:redirect ليشير إلى المجال 300-399، أو ‎:missing ليشير إلى 404، أو ‎:error ليشير إلى المجال 500-599. يمكنك أيضًا تمرير رقم حالة مجرد أو رمزه المقابل. لمزيد من المعلومات، اطلع على قائمة رموز الحالة الكاملة وكيفية إعادة تعيينها.
assert_redirected_to(options = {}, message=nil)‎	اختبار خيارات إعادة التوجيه الممررة والتأكد من مطابقتها لتلك المُمرَّرة إلى عملية إعادة التوجيه المستدعاة في أحدث إجراء. يمكن أن تكون هذه المطابقة جزئية مثل assert_redirected_to(controller: "weblog")‎ الذي سيطابق أيَضًا إعادة التوجيه redirect_to(controller: "weblog", action: "show")‎ وهلم جرًا. يمكنك أيضًا تمرير مسارات موجهة مسماة مثل assert_redirected_to root_path وكائنات سجل فعال مثل assert_redirected_to @article.

ستتطرّق إلى استعمالات بعض هذه التحقّقات في الفصل القادم.

ملاحظة وجيزة حول حالات الاختبار

جميع التحقّقات الأساسيّة المُعرّفة في Minitest::Assertions مُتاحة أيضًا في الأصناف التي نستعملها في حالات الاختبار الخاصّة بنا. يُوفّر لك ريلز الأصناف الآتية لترِث منها:

• ActiveSupport::TestCase
• ActionMailer::TestCase
• ActionView::TestCase
• ActiveJob::TestCase
• ActionDispatch::IntegrationTest
• ActionDispatch::SystemTestCase
• Rails::Generators::TestCase

تتضمّن كلّ هذه الأصناف Minitest::Assertions ممّا يُمكّننا من استعمال جميع التحقّقات الأساسيّة في الاختبارات الخاصّة بنا.

ملاحظة: لمزيد من المعلومات حول Minitest، يُرجى الرّجوع إلى التوثيق الخاصّ بها.

منفذ الاختبارات في ريلز

من الممكن تنفيذ جميع الاختبارات دفعة واحدة باستعمال الأمر bin/rails test. كما يمكننا أن ننفّذ اختبارًا واحدًا من خلال تمرير اسم الملفّ الذي يحوي حالات الاختبار للأمر bin/rails test.

$ bin/rails test test/models/article_test.rb
Run options: --seed 1559
 
# Running:
 
..
 
Finished in 0.027034s, 73.9810 runs/s, 110.9715 assertions/s.
 
2 runs, 3 assertions, 0 failures, 0 errors, 0 skips

سيُنفّذ هذا كلّ توابع الاختبار في حالة الاختبار هذه. يُمكن أيضًا تنفيذ تابع اختبار معيّن في حالة الاختبار من خلال إعطاء الراية ‎-n‎‎‎ أو ‎--name‎ بالإضافة إلى اسم تابع الاختبار.

$ bin/rails test test/models/article_test.rb -n test_the_truth
Run options: -n test_the_truth --seed 43583
 
# Running:
 
.
 
Finished tests in 0.009064s, 110.3266 tests/s, 110.3266 assertions/s.
 
1 tests, 1 assertions, 0 failures, 0 errors, 0 skips

يُمكنك أيضًا تنفيذ سطرٍ معيّن من الاختبار وذلك بإعطاء رقمه:

$ bin/rails test test/models/article_test.rb:6 # تنفيذ سطر محدد من الاختبار

بالإضافة إلى ذلك، يُمكنك تنفيذ مجلّد كامل من الاختبارات من خلال إعطاء المسار إلى هذا المجلّد:

$ bin/rails test test/controllers # تنفيذ جميع الاختبارات الواقعة في مجلد محدد

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

$ bin/rails test -h
minitest options:
    -h, --help                       Display this help.
    -s, --seed SEED                  Sets random seed. Also via env. Eg: SEED=n rake
    -v, --verbose                    Verbose. Show progress processing files.
    -n, --name PATTERN               Filter run on /regexp/ or string.
        --exclude PATTERN            Exclude /regexp/ or string from run.
 
Known extensions: rails, pride
 
Usage: bin/rails test [options] [files or directories]
You can run a single test by appending a line number to a filename:
 
    bin/rails test test/models/user_test.rb:27
 
You can run multiple files and directories at the same time:
 
    bin/rails test test/controllers test/integration/login_test.rb
 
By default test failures and errors are reported inline during a run.
 
Rails options:
    -w, --warnings                   Run with Ruby warnings enabled
    -e, --environment                Run tests in the ENV environment
    -b, --backtrace                  Show the complete backtrace
    -d, --defer-output               Output test failures and errors after the test run
    -f, --fail-fast                  Abort test run on first failure or error
    -c, --[no-]color                 Enable color in the output

قاعدة بيانات الاختبارات

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

لكلّ تطبيق ريلز ثلاث بيئات افتراضيّة: بيئة التطوير، بيئة الاختبار، وبيئة الإنتاج. تُضبط قاعدة البيانات لكلٍّ من هذه البيئات في الملف config/database.yml.

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

صيانة مخطط قاعدة بيانات الاختبار

لتنفيذ الاختبارات الخاصّة بك، يجب أن تكون قاعدة البيانات ذات بنية حالّية. يبحث مساعد الاختبار عمّا إذا كان لقاعدة البيانات تهجيرات معلّقة، وذلك بمحاولة تحميل db/schema.rb أو db/structure.sql الخاصّين بك في قاعدة البيانات. فإن كانت هناك تهجيرات لا تزال معلّقة، يتمّ إطلاق خطأ. يدلّ هذا عادةً على أنَّ المخطّط الخاصّ بك لم يُهجّر كليّةً، ويمكن تحديثه عن طريق إجراء التهجيرات مقابل قاعدة بيانات التطوير (عبر الأمر bin/rails db:migrate).    

ملاحظة: إذا أُحدِثت تغييرات على تهجيرات حاليّة، فلابد من إعادة بناء قاعدة البيانات. يمكن فعل ذلك عن طريق تنفيذ الأمر bin/rails db:test:prepare.

حقيقة تحضيرات الاختبار (Fixtures)

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

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

تحضيرات الاختبار (Fixtures) هو إطلاق مزخرف على "عيّنات البيانات" (sample data). تمكّنك تحضيرات الاختبارات (Fixtures) من تعمير قاعدة بيانات الاختبار ببيانات معرّفة مسبقًا قبل تنفيذ الاختبار. تُكتب التحضيرات بلغة YAML و تكون مستقلّة عن قاعدة البيانات. يوجد هناك ملفّ واحد لكلّ نموذج.

ملاحظة: ليست التحضيرات (Fixtures) مصمَّمة لإنشاء جميع الكائنات التي تحتاجها اختباراتك، وتكون إدارتها أفضل عندما تُستعمل مع البيانات الافتراضيّة التي يمكن تطبيقها في الحالة الشائعة.

بإمكانك إيجاد تحضيرات الاختبار (Fixtures) في المجلّد test/fixtures. عندما تنفّذ الأمر rails generate model لإنشاء نموذج جديد، يُنشئ ريلز بذورًا للحضيرات (fixture stubs) في هذا المجلّد.

YAML

تعتبر التحضيرات المكتوبة بصياغة YAML طريقةً لتمثيل عيّنات البيانات على نحوٍ يفهمه البشر. يكون لهذا النوع التحضيرات الامتداد ‎.yml (كما في users.yml).

إليك عيّنة من ملفّ تحضيرات مكتوب بصياغة YAML:

# lo & behold! I am a YAML comment!
david:
  name: David Heinemeier Hansson
  birthday: 1979-10-15
  profession: Systems development
 
steve:
  name: Steve Ross Kellock
  birthday: 1974-09-27
  profession: guy with keyboard

يُعطى لكلّ تحضير (Fixture) اسمًا متبوعًا بقائمة مزاحة للأزواج مفتاح/قيمة المفصولة عن بعضها بنقطتين رأسيّتين. تُفصل السجلّات عادة بسطر فارغ. بإمكانك وضع تعليقات في ملفّ التحضيرات (Fixture) باستخدام المحرف # كما في السطر الأوّل. إذا كنت تستخدم الارتباطات، يمكنك تعريف عقدة مرجعيّة بين كلّ تحضيرين مختلفتين. إليك مثالًا بارتباط من النوع belongs_to/has_many:

# In fixtures/categories.yml
about:
  name: About
 
# In fixtures/articles.yml
first:
  title: Welcome to Rails!
  body: Hello world!
  category: about

لاحظ أنّ قيمة المفتاح category للمقال first الموجود في fixtures/articles.yml هي about. يطلب هذا من ريلز تحميل الفئة about الموجودة في fixtures/categories.yml.

ملاحظة: لتمكين الارتباطات من الإشارة إلى بعضها البعض بالاسم، يمكنك استعمال اسم التحضير (Fixture) بدل تحديد الخاصية id:‎ في التحضيرات المرتبطة بها. يعيّين ريلز بشكلٍ آليّ مفتاحًا رئيسيًّا حتى يضمن التناسق بين جميع التنفيذات. لمزيد من المعلومات حول تصرّف الارتباطات هذا، يرجى الاطلاع على توثيق الواجهة البرمجية للتحضيرات.

وجود ERB

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

<% 1000.times do |n| %>
user_<%= n %>:
  username: <%= "user#{n}" %>
  email: <%= "user#{n}@example.com" %>
<% end %>

التحضيرات في موقع العمل

يحمّل ريلز تلقائيًا جميع التحضيرات (Fixtures) من المجلّد test/fixtures بشكل افتراضي، وتتكوّن عملية التحميل من ثلاثة خطوات:

1. إزالة أي بيانات موجودة من الجدول المقابل للتحضير (Fixture).
2. تحميل بيانات التحضير إلى الجدّول.
3. تفريغ بيانات التحضير إلى تابع في حالة كنت ترغب في الوصول إليه بشكل مباشر.

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

التحضيرات هي كائنات السجل الفعال

إن التحضيرات (Fixtures) هي أمثلة للسجل الفعال؛ وكما ذكرنا في النقطة الثالثة أعلاه، يمكنك الوصول إلى الكائن مباشرةً لأنه متوفّر تلقائيًا كتابع حيث أن نطاقه محلي هو حالة الاختبار. فمثلًا:

# david للتحضير الذي يدعى User هذا سيعيد الكائن
users(:david)
 
# david للتحضير it هذا سيعيد الخاصية
users(:david).id
 
# عبر User يمكن الوصول إلى التوابع الموجودة في الصنف
david = users(:david)
david.call(david.partner)

للحصول على تحضيرات متعددة في وقت واحد، يمكنك تمرير قائمة من أسماء التحضيرات مثل:

# david و steve هذا سيعيد مصفوفة تحوي التحضيرين
users(:david, :steve)

اختبار النموذج

يهدف اختبار النماذج لاختبار نماذج مختلفة من تطبيقك الخاص.

تُخزّن اختبارات نماذج ريلز في المجلّد test/models ويوفّر لك ريلز مولّدًا لإنشاء هيكل اختبار النموذج:

$ bin/rails generate test_unit:model article title:string body:text
create  test/models/article_test.rb
create  test/fixtures/articles.yml

لا تملك اختبارات النموذج صنفًا فرعيًا (superclass) خاصًّا بها مثل ActionMailer::TestCase؛ وبدلًا من ذلك، ترث من ActiveSupport::TestCase.

اختبار النظام

تسمح لك اختبارات النظام (system tests) باختبار تفاعلات المستخدم مع تطبيقك، أو تشغيل الاختبارات في متصفح حقيقي أو في متصفّح بدون رأس (headless browser، أي متصفح ويب ولكن بدون واجهة المستخدم الرسومية)؛ ومن الداخل، تستخدم اختبارات النظام Capybara.

لإنشاء اختبارات نظام ريلز، يمكنك استخدام المجلّد test/system في تطبيقك، وسيوفّر ريلز مولّدًا لإنشاء هيكل اختبار النظام:

$ bin/rails generate system_test users
      invoke test_unit
      create test/system/users_test.rb

وهذا ما سيبدو عليه اختبار نظام أُنشئ حديثًا:

require "application_system_test_case"
 
class UsersTest < ApplicationSystemTestCase
  # test "visiting the index" do
  #   visit users_url
  #
  #   assert_selector "h1", text: "Users"
  # end
end

تعمل اختبارات النظام بشكل افتراضي باستخدام المشغّل Selenium والمتصفح Chrome وشاشة بحجم 1400x1400، ويوضح القسم التالي كيفيّة تغيير الإعدادات الإفتراضيّة.

تغيير الإعدادات الافتراضية

يجعل ريلز عمليّة تغيير الإعدادات الافتراضيّة لاختبارات النظام بسيطة للغاية، فاستُخرجت جميع الإعدادات بعيدا حتى تتمكن من التركيز على كتابة الاختبارات الخاصة بك.

يُنشئ ملف جديد باسم application_system_test_case.rb في المجلد test عند إنشاء تطبيق جديد أو توليد تطبيق عبر scaffold، وهنا ستكون جميع إعدادات نظام الاختبارات موجودة.

إذا رغبّت بتغيير الإعدادات الافتراضيّة، يمكنك تغيير مشغّل نظام الاختبارات؛ فلنفترض أنك ترغب في تغيير المشغل من Selenium إلى Poltergeist، يجب عليك أولًا إضافة الجوهرة poltergeist إلى Gemfile ومن ثم، عّدل على الملف application_system_test_case.rb بالشكل التالي:

require "test_helper"
require "capybara/poltergeist"
 
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :poltergeist
end

اسم المشغل هو معامل إجباري من أجل driven_by، ويمكنك إضافة المعاملات الاختيارية التالية:

• ‎:using: للمتصفح (يُستخدم فقط مع Selenium)، و
• ‎:screen_size: لتغيير حجم الشاشة للقطات الشاشة (Screenshots)، و
• ‎:options: لتحديد وضبط الخيارات المدعومة من قبل المشغّل.

require "test_helper"
 
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :firefox
end

إذا أردت استخدام متصفح بلا رأس (headless browser)، فيمكنك استخدام متصفح Chrome بلا رأس أو متصفح Firefox بلا رأس وذلك عن طريق إضافة headless_chrome أو headless_firefox في المعامل :using:

require "test_helper"
 
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :headless_chrome
end

إذا كانت إعدادات Capybara تتطلّب ضبطًا أكثر مما توفره ريلز، فيجب إضافة هذه الإعدادات الإضافيّة إلى الملف application_system_test_case.rb.

يرجى الإطلاع على توثيق Capybara للاطلاع على الإعدادات الإضافيّة.

مساعد إلتقاط الشاشة

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

هنالك تابعين هما: take_screenshot و take_failed_screenshot، وهذا الأخير موجود تلقائيًا في after_teardown داخل ريلز.

يمكنك تضمين تابع المساعد take_screenshot في أي مكان في اختباراتك لالتقاط لقطة شاشة للمتصفح.

تنفيذ اختبار النظام

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

إذا استخدمت المولّد scaffold، فسيُنشئ لك هيكل اختبار للنظام تلقائيًا؛ وإذا لم تستخدمه، فابدأ بإنشاء هيكل اختبار للنظام عبر الأمر التالي:

$ bin/rails generate system_test articles

سيُنشئ لنا هذا ملف اختبار جاهز، وستكون هذه مخرجات الأمر السابق:

invoke  test_unit
create    test/system/articles_test.rb

دعونا الآن نفتح هذا الملف ونكتب اختبارنا (assertion) الأول:

require "application_system_test_case"
 
class ArticlesTest < ApplicationSystemTestCase
  test "viewing the index" do
    visit articles_path
    assert_selector "h1", text: "Articles"
  end
end

يجب أن يبحث الاختبار على العنوان h1 الموجود في صفحة المقالات الرئيسية ويمرره. شغّل الآن اختبارات النظام:

bin/rails test:system

ملاحظة: بشكل افتراضي، لن يشغّل الأمر bin/rails test اختبارات النظام الخاصة بك، لذا تأكد من تنفيذ bin/rails test:system لتشغيلها.

إنشاء اختبار نظام للمقالات

دعونا الآن نختبر سير عملية إنشاء مقال جديد في مدونتنا:

test "creating an article" do
  visit articles_path
 
  click_on "New Article"
 
  fill_in "Title", with: "Creating an Article"
  fill_in "Body", with: "Created this article successfully!"
 
  click_on "Create Article"
 
  assert_text "Creating an Article"
end

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

بعد ذلك، سيجد click_on "New Article"‎ الزر "New Article" في صفحة الرئيسية. وسيؤدي هذا إلى إعادة توجيه المتصفح إلى ‎/articles/new.

بعد ذلك سيكتب الاختبار عنوانًا ونصًا للمقال في المكان المحدد، وسينقر، بمجرّد ملء الحقول، على  "Create Article" لسيُرسَل طلب POST لإنشاء مقال جديد في قاعدة البيانات.

سيُعاد توجيهنا إلى صفحة فهرس المقالات (الصفحة الرئيسية) وهنالك سنتأكد من أن المحتوى النصي لعنوان المقال الجديد موجود في صفحة فهرس المقالات.

الغوص أكثر

يكمن جمال اختبار النظام في أنه يشبه اختبار التكامل (integration testing) من حيث أنه يختبر تفاعل المستخدم مع المتحكم، والنموذج، والعرض، ولكن اختبار النظام أكثر قوّة منه ويختبر التطبيق فعليًَا كما لو كان المستخدم الحقيقي يستخدمه؛ ويمكِّنك فعل أكثر من ذلك، إذ يمكنك من اختبار ما يمكن للمستخدم نفسه فعله عند استخدام تطبيقك مثل التعليق، حذف المقالات، نشر المقالات، ...إلخ.

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

تُستخدم اختبارات التكامل (Integration tests) لاختبار كيّفيّة تفاعل أجزاء مختلفة من تطبيقك، وتُستخدم بشكل عام لاختبار سير العمل المهم داخل التطبيق.

لإنشاء اختبارات التكامل في ريلز، نستخدم المجلّد test/integration لتطبيقنا، ويوفّر ريلز مولدًا لإنشاء هيكل اختبار تكامل لنا.

$ bin/rails generate integration_test user_flows
      exists  test/integration/
      create  test/integration/user_flows_test.rb

هذا ما سيبدو عليه اختبار تكامل أنشئ حديثًا:

require 'test_helper'
 
class UserFlowsTest < ActionDispatch::IntegrationTest
  # test "the truth" do
  #   assert true
  # end
end

يرث الاختبار من ActionDispatch::IntegrationTest، ويتيح هذا لنا بعض المساعدين الإضافيين لاستخدامهم في اختبارات التكامل الخاصة بنا.

المساعدين المتاحين لاختبارات التكامل

بالإضافة إلى مساعدي الاختبارات القياسيّة، تأتي الوراثة من ActionDispatch::IntegrationTest مع بعض المساعدين الإضافيين المتوفرين عند كتابة اختبارات التكامل، دعونا نقدم لك باختصار الفئات الثلاثة التي يجب أن نختار منهم:

1. للتعامل مع مشغل (runner) اختبار التكامل، راجع ActionDispatch::Integration::Runner.
2. عند تنفيذ الطلبات، سيتاح لنا ActionDispatch::Integration::RequestHelpers للاستخدام.
3. إذا أردت تعديل الجلسة، أو حالة اختبار التكامل، فألقي نظّرة على ActionDispatch::Integration::Session لمساعدتك.

تنفيذ اختبار التكامل

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

سنبدأ بتوليد هيكل اختبار تكامل خاص بنا:

$ bin/rails generate integration_test blog_flow

سينشئ لنا هذا ملف الاختبار، وسيخّرج لنا الأمر السابق ما يلي:

invoke  test_unit
create    test/integration/blog_flow_test.rb

الآن، دعونا نفتح هذا الملف ونكتب اختبارنا (assertion) الأول:

require 'test_helper'
 
class BlogFlowTest < ActionDispatch::IntegrationTest
  test "can see the welcome page" do
    get "/"
    assert_select "h1", "Welcome#index"
  end
end

سنلقي نظّرة على assert_select للاستعلام عن شيفرة HTML الناتجة عن طلب في قسم "Testing Views" الموجود في الأسفل؛ ويُستخدم لاختبار استجابة طلبنا من خلال التأكيد على وجود عناصر HTML الأساسيّة ومحتوياتها.

عندما نزور مسارنا الجذر، ينبغي أن نرى الملف welcome/index.html.erb مصيَّرًا للعرض، ولذلك يجب أن يتحقق هذا التأكيد.

إنشاء تكاملات المقالات

ما رأيك أن نختبر قدرتنا على إنشاء مقالة جديدة في مدونتنا والإطلاع على المقالة الناتجة؟ إليك الشيفرة التالية:

test "can create an article" do
  get "/articles/new"
  assert_response :success
 
  post "/articles",
    params: { article: { title: "can create", body: "article successfully." } }
  assert_response :redirect
  follow_redirect!
  assert_response :success
  assert_select "p", "Title:\n  can create"
end

دعونا نقسّم هذا الاختبار حتى نفهمه.

نبدأ باستدعاء الإجراء :new على المتحكم Articles، ويجب أن تكون نتيجة هذه الاستجابة ناجحة.

بعد ذلك، نرسل طلبًا للنشر (post) إلى الإجراء ‎:create للمتحكم Articles:

post "/articles",
  params: { article: { title: "can create", body: "article successfully." } }
assert_response :redirect
follow_redirect!

السطران التاليان للطلب هما للتعامل مع عملية إعادة التوجيه التي قمنا بإعدادها عند إنشاء مقالة جديدة.

ملاحظة: لا تنس أن تستدعي follow_redirect!‎ إذا كنت تخطط لتقديم طلبات لاحقة بعد إجراء إعادة التوجيه.

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

الغوص أكثر

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

الاختبارات الوظيفية لوحدات التحكم الخاصة بنا

في ريلز، اختبار الإجراءات المختلفة للمتحكم هو شكل من أشكال كتابة الاختبارات الوظيفيّة؛ تذكر أن وحدات التحكم الخاصة بك تتعامل مع طلبات الويب الواردة إلى التطبيق الخاص بك وتستجيب في النهاية مع عرض مصيَّر (rendered view). وعند كتابة الاختبارات الوظيفيّة، فإنك تختبر كيف تتعامل الإجراءات مع الطلبات والنتائج المتوقعة أو الاستجابة وفي بعض الحالات عرض شيفرة HTML.

ما يجب تضمينه في اختباراتك الوظيفية

يجب عليك اختبار أشياء مثل:

• هل كان طلب الويب ناجحًا؟
• هل أُعيد توجيه المستخدم إلى الصفحة الصحيحة؟
• هل تمت مصادقة المستخدم بنجاح؟
• هل كان الكائن الصحيح مخزّن في قالب الاستجابة؟
• هل كانت الرسالة المناسبة معروضة للمستخدم في العرض؟

أسهل طريقة لرؤية الاختبارات الوظيفيّة في العمل هي إنشاء وحدة تحكم باستخدام المولّد scaffold:

$ bin/rails generate scaffold_controller article title:string body:text
...
create  app/controllers/articles_controller.rb
...
invoke  test_unit
create    test/controllers/articles_controller_test.rb
...

سيُنشئ هذا الشيفرة البرمجيّة للمتحكم والاختبارات للمورد Article؛ يمكنك إلقاء نظرة  على الملف articles_controller_test.rb في المجلد test/controllers. إذا كان لديك متحكمًا بالفعل وترغب فقط في إنشاء شيفرة اختبار scaffold لكل إجراء من إجراءات السبعة الافتراضيّة، فيمكنك استخدام الأمر التالي:

$ bin/rails generate test_unit:scaffold article
...
invoke  test_unit
create    test/controllers/articles_controller_test.rb
...

لنقِ نظرة على اختبار واحد من هذا القبيل وهو test_should_get_index من الملف articles_controller_test.rb:

# articles_controller_test.rb
class ArticlesControllerTest < ActionDispatch::IntegrationTest
  test "should get index" do
    get articles_url
    assert_response :success
  end
end

في الاختبار test_should_get_index، يحاكي ريلز طلبًا على الإجراء index مع التأكد من نجاح الطلب وضمان إنشاء جسم (body) الاستجابة الصحيح أيضًا.

يحصل التابع get على طلب الويب ويعبئ النتائج في ‎@response، ويقبل هذا 6 معاملات:

• عنوان URI: لإجراء المتحكم الذي تطلبه، ويمكن أن يكون هذا على شكل سلسلة نصيّة أو مساعد مسار توجيه (على سبيل المثال articles_url).
• Params: خيار مع جدول hash من معاملات الطلب لتمريرها إلى الإجراء (على سبيل المثال معاملات سلسلة النصية للطلب أو متغيرات المقال).
• headers: لتعيين الرؤوس التي ستمرّر مع الطلب.
• env: لتخصيص بيئة الطلب حسب الحاجة.
• xhr: مهما كان الطلب هو طلب Ajax أو لا، فيمكنك تعيين هذا الخيار إلى القيمة true لجعل الطلب هو طلب Ajax.
• as: لتشفير الطلب بنوع محتوى مختلف، وهو يدعم ‎:json بشكل افتراضي.

جميع معاملات الكلمات الرئيسيّة هذه اختياريّة.

مثال: استدعاء الإجراء ‎:show للمقال الأول، وتمرير الترويسة HTTP_REFERER:

get article_url(Article.first), headers: { "HTTP_REFERER" => "http://example.com/home" }

مثال آخر: استدعاء الإجراء ‎:update للمقال الأخير، وتمرير نص جديد للعنوان في params، وسنجعله طلب Ajax:

patch article_url(Article.last), params: { article: { title: "updated" } }, xhr: true

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

test "should create article" do
  assert_difference('Article.count') do
    post articles_url, params: { article: { body: 'Rails is awesome!', title: 'Hello Rails' } }
  end
 
  assert_redirected_to article_path(Article.last)
end

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

request.headers['Authorization'] = ActionController::HttpAuthentication::Basic.
  encode_credentials('dhh', 'secret')

أنواع الطلبات المتاحة للاختبارات الوظيفية

إذا كنت معتادًا على بروتوكول HTTP، فستعرف أن get هو نوع من أنواع الطلبات، وهنالك 6 أنواع طلبات مدعومة في اختبارات ريلز الوظيفيّة هي:

• get
• post
• patch
• put
• head
• delete

تحتوي جميع أنواع الطلبات على توابع مكافئة يمكنك استخدامها. وستستعمل get و post و put و delete كثيرًا في تطبيق C.R.U.D العادي.

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

اختبارات طلبات AJAX) XHR)

لاختبار طلبات AJAX، يمكنك تحديد الخيار xhr: true للتوابع get، و post، و patch، و put، و delete. فعلى سبيل المثال:

test "ajax request" do
  article = articles(:one)
  get article_url(article), xhr: true
 
  assert_equal 'hello world', @response.body
  assert_equal "text/javascript", @response.content_type
end

ثلاثة جداول Hash

بعد إجراء الطلب ومعالجته، سيكون لدينا ثلاثة كائنات من Hash جاهزة للاستخدام هي:

• cookies: لملفات تعريف الارتباط التي عيّناها.
• flash: لأي كائنات موجودة في flash.
• session: لأي كائنات موجودة في متغيرات الجلسة.

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

flash["gordon"]               flash[:gordon]
session["shmession"]          session[:shmession]
cookies["are_good_for_u"]     cookies[:are_good_for_u]

متغيرات النسخة المتاحة

يمكنك أيضًا الوصول إلى ثلاثة متغيّرات نسخة في اختباراتك الوظيفيّة بعد إجراء الطلب هي:

• ‎@controller: المتحكم المعالج للطلب.
• ‎@request: كائن الطلب.
• ‎@response: كائن الاستجابة.

  class ArticlesControllerTest < ActionDispatch::IntegrationTest
    test "should get index" do
      get articles_url
   
      assert_equal "index", @controller.action_name
      assert_equal "application/x-www-form-urlencoded", @request.media_type
      assert_match "Articles", @response.body
    end
  end
  

إعداد الترويسات ومتغيرات CGI

يمكن تمرير ترويسات HTTP ومتغيرات CGI كترويسات مثل:

# HTTP ضبط ترويسة
get articles_url, headers: { "Content-Type": "text/plain" } 
# محاكاة الطلب مع ترويسة مخصصة
 
# CGI ضبط متغير
get articles_url, headers: { "HTTP_REFERER": "http://example.com/home" } 
# مخصص (env variable) محاكاة الطلب مع متغير بيئة

اختبار الاشعارات الوامضة

إذا كنت تتذكر، أحد الجداول hash الثلاثة آنفة الذكر كان flash.

نرغب الآن في إظهار رسالة وامضة (رسالة flash) إلى تطبيق المدونة كلما نجح أحدهم في إنشاء مقالة جديدة.

لنبدأ بإضافة هذا التأكيد إلى الاختبار test_should_create_article:

test "should create article" do
  assert_difference('Article.count') do
    post article_url, params: { article: { title: 'Some title' } }
  end
 
  assert_redirected_to article_path(Article.last)
  assert_equal 'Article was successfully created.', flash[:notice]
end

إذا أجرينا الاختبار الآن، فمن المفترض أن نرى رسالة الفشل:

$ bin/rails test test/controllers/articles_controller_test.rb -n test_should_create_article
Run options: -n test_should_create_article --seed 32266
 
# Running:
 
F
 
Finished in 0.114870s, 8.7055 runs/s, 34.8220 assertions/s.
 
  1) Failure:
ArticlesControllerTest#test_should_create_article [/test/controllers/articles_controller_test.rb:16]:
--- expected
+++ actual
@@ -1 +1 @@
-"Article was successfully created."
+nil
 
1 runs, 4 assertions, 1 failures, 0 errors, 0 skips

لننفّذ الرسالة الوامضة الآن على متحكمنا، إذ سيبدو الإجراء :create الآن كالتالي:

def create
  @article = Article.new(article_params)
 
  if @article.save
    flash[:notice] = 'Article was successfully created.'
    redirect_to @article
  else
    render 'new'
  end
end

والآن إذا أجرينا اختباراتنا، فستنجح:

$ bin/rails test test/controllers/articles_controller_test.rb -n test_should_create_article
Run options: -n test_should_create_article --seed 18981
 
# Running:
 
.
 
Finished in 0.081972s, 12.1993 runs/s, 48.7972 assertions/s.
 
1 runs, 4 assertions, 0 failures, 0 errors, 0 skips

جمع كل شيء معًا

في هذه المرحلة، يختبر متحكم مقالاتنا الإجراءات :index و :new و ‎:create. فماذا عن التعامل مع البيانات الموجودة؟

دعونا نكتب اختبار للإجراء :show:

test "should show article" do
  article = articles(:one)
  get article_url(article)
  assert_response :success
end

تذكر من مناقشتنا في وقت سابق عن تحضيرات الاختبار (Fixtures)، سيعطينا التابع ()articles إمكانيّة الوصول إلى تحضيرات مقالاتنا. فماذا عن حذف مقالة موجودة؟

test "should destroy article" do
  article = articles(:one)
  assert_difference('Article.count', -1) do
    delete article_url(article)
  end
 
  assert_redirected_to articles_path
end

يمكننا أيضًا إضافة اختبار لتحديث مقالة موجودة.

test "should update article" do
  article = articles(:one)
 
  patch article_url(article), params: { article: { title: "updated" } }
 
  assert_redirected_to article_path(article)
  # Reload association to fetch updated data and assert that title is updated.
  article.reload
  assert_equal "updated", article.title
end

لاحظ أننا بدأنا نرى بعض التكرارات في هذه الاختبارات الثلاثة، فهم يصلون إلى نفس بيانات تحضير (Fixture) المقالة، ويمكنك تجنب تكرار هذا (مبدأ لا تكرر نفسك [[[wikipedia:Don't_repeat_yourself|D.R.Y.‎]]]) عن طريق استخدام التابعين setup و teardown التي يوفّرها ActiveSupport::Callbacks. يجب أن يظهر اختبارنا كالتالي (تجاهل الاختبارات الأخرى في الوقت الحالي، فنحن نتناساهم للإيجاز):

require 'test_helper'
 
class ArticlesControllerTest < ActionDispatch::IntegrationTest
  # يستدعى قبل كل عملية اختبار فردية
  setup do
    @article = articles(:one)
  end
 
  # يستدعى بعد كل عملية اختبار فردية
  teardown do
    # فمن الأفضل إعادة ضبطها بعد ذلك ،cache عندما يستعمل المتحكم
    Rails.cache.clear
  end
 
  test "should show article" do
    # (setup) من الضبط @article إعادة استعمال متغير النسخة
    get article_url(@article)
    assert_response :success
  end
 
  test "should destroy article" do
    assert_difference('Article.count', -1) do
      delete article_url(@article)
    end
 
    assert_redirected_to articles_path
  end
 
  test "should update article" do
    patch article_url(@article), params: { article: { title: "updated" } }
 
    assert_redirected_to article_path(@article)
    # إعادة تحميل الاختبار لجلب البيانات المحدثة والتأكد من تحديث العنوان
    @article.reload
    assert_equal "updated", @article.title
  end
end

وعلى غرار الاستدعاءات الأخرى في ريلز، يمكن أيضًا استخدام التابعين setup و teardown عن طريق تمرير كتلة، أو تعبير lambda، أو اسم تابع كرمز للاستدعاء.

مساعدي الاختبار

لتجنب تكرار الشيفرات البرمجيّة، يمكنك إضافة مساعدي الاختبار الخاصين بك،  ويمكن أن يكون مساعد تسجيل الدخول مثال جيد على ذلك:

# test/test_helper.rb
 
module SignInHelper
  def sign_in_as(user)
    post sign_in_url(email: user.email, password: user.password)
  end
end
 
class ActionDispatch::IntegrationTest
  include SignInHelper
end

require 'test_helper'
 
class ProfileControllerTest < ActionDispatch::IntegrationTest
 
  test "should show profile" do
    # أصبح المساعد الآن قابلًا لإعادة الاستعمال من أي حالة اختبار لمتحكم
    sign_in_as users(:david)
 
    get profile_url
    assert_response :success
  end
end

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

مثل كل شيء آخر في تطبيق ريلز، يمكنك اختبار مسارات التوجيه (routes) الخاصة بك، إذ تتوضع هذه الاختبارات في test/controllers/‎ أو ستكون جزءًا من اختبارات وحدة التحكم.

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

لمزيد من المعلومات حول تأكيدات التوجيه المتاحة في ريلز، راجع توثيق الواجهة البرمجية لـ ActionDispatch::Assertions::RoutingAssertions.

اختبار العروض

يعدّ اختبار الاستجابة لطلبك من خلال التأكيد على وجود عناصر HTML الأساسيّة ومحتواها طريقةً شائعةً لاختبار طرق عرض التطبيق. بشكل مشابه لاختبارات مسار التوجيه، تقع اختبارات العرض في test/controllers/‎ أو كجزء من اختبارات المتحكم. يسمح لك التابع assert_select الاستعلام عن عناصر HTML للاستجابة باستخدام صيغة بسيطة لكنها قويّة.

هنالك نوعا من assert_select:

• assert_select(selector, [equality], [message])‎: يتأكد من استيفاء شرط المساواة على العناصر المحددة من خلال المحدّد (selector)، وقد يكون هذا الأخير عبارة عن تعبير محدِّد CSS (سلسلة نصيّة) أو تعبير يحتوي على قيم بديلة.

• assert_select(element, selector, [equality], [message])‎: يتأكد من استيفاء شرط المساواة على كل العناصر المحددة من خلال المحدّد بدءًا من العنصر (نسخة من Nokogiri::XML::Node أو Nokogiri::XML::NodeSet) وأبنائه.

على سبيل المثال، يمكنك التحقق من محتويات عنصر العنوان في استجابتك باستخدام:

assert_select 'title', "Welcome to Rails Testing Guide"

يمكنك أيضًا استخدام كتل assert_select المتداخلة للتحقق بعمق أكبر. في المثال التالي، ينفَّذ assert_select الداخلي من أجل li.menu_item ضمن مجموعة العناصر المحدّدة بواسطة الكتلة الخارجيّة:

assert_select 'ul.navigation' do
  assert_select 'li.menu_item'
end

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

assert_select "ol" do |elements|
  elements.each do |element|
    assert_select element, "li", 4
  end
end
 
assert_select "ol" do
  assert_select "li", 8
end

هذا التأكيد قوي جدًا؛ لمزيد من الاستخدام المتقدم، راجع التوثيق الخاص به.

تأكيدات إضافية تستند إلى العرض

هنالك المزيد من التأكيدات التي تستخدم في المقام الأول في اختبار العروض:

التأكيد	الغرض
assert_select_email	يتيح لك تقديم تأكيدات على نص رسالة البريد الإلكتروني.
assert_select_encoded	يتيح لك تقديم التأكيدات على شيفرة HTML مشفّرة، وذلك عن طريق إلغاء تشفير محتويات كل عنصر ومن ثم استدعاء الكتلة مع جميع العناصر غير المشفّرة.
css_select(selector)‎ أو css_select(element, selector)‎	يعيد مصفوفة بكافة العناصر المحّددة بواسطة المحددّ selector. في النوع الثاني، يطابق أولًا العنصر element الأساسي ويحاول مطابقة التعبير المحدّد selector على أحد أبنائه، وإذا لم يكن هنالك مطابقات، فسيعيد كلا المتغيريّن مصفوفة فارغة.

في ما يلي مثال على استخدام assert_select_email:

assert_select_email do
  assert_select 'small', 'Please click the "Unsubscribe" link if you want to opt-out.'
end

اختبار المساعدين

المساعد هو مجرّد وحدة بسيطة حيث يمكنك تعريف التوابع المتاحة في عروضك.

من أجل اختبار المساعدين، كل ما عليك القيام به هو التحقق من أن ناتج تابع المساعد يطابق ما تتوقعه، وتقع الاختبارات المتعلّقة بالمساعدين في المجلد test/helpers.

فإذا كان لدينا المساعد التالي:

module UsersHelper
  def link_to_user(user)
    link_to "#{user.first_name} #{user.last_name}", user
  end
end

فيمكننا اختبار ناتج هذا التابع كالتالي:

class UsersHelperTest < ActionView::TestCase
  test "should return the user's full name" do
    user = users(:david)
 
    assert_dom_equal %{<a href="/user/#{user.id}">David Heinemeier Hansson</a>}, link_to_user(user)
  end
end

علاوة على ذلك، نظرًا لأن الصنف test موسع (extend) من ActionView::TestCase، يمكنك الوصول إلى توابع مساعدة ريلز مثل link_to أو pluralize.

اختبار إجراء المراسلة الخاص بك

يتطلب اختبار الأصناف mailer بعض الأدوات المحدّدة للقيام بكامل المهمة.

الحفاظ على Postman في التحقق

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

الهدف من اختبار الأصناف mailer هو التأكد من:

• معالجة رسائل البريد الإلكتروني (الإنشاء والإرسال).
• أن يكون محتوى البريد الإلكتروني صحيحًا (الموضوع، والمُرسِل، والمحتوى، ...إلخ.)
• إرسال رسائل البريد الإلكتروني الصحيحة في الوقت المناسب.

من جميع الجوانب

هنالك جانبان لاختبار البريد الإلكتروني، اختبارات الوحدة (unit tests) والاختبارات الوظيفيّة (functional tests). ففي اختبارات الوحدة، نشغّل المرسل (mailer) بعزله مع مدخلات متحكم بها ونقارن المخرجات مع قيمة معروفة (Fixture). وفي الاختبارات الوظيفيّة، لا تختبر الكثير من التفاصيل الدقيقة التي ينتجها المرسل؛ وبدلًا من ذلك، نختبر أن وحدات التحكم والنماذج الخاصة بنا تستخدم المرسل بالطريقة الصحيحة، ويكون هذا الاختبار هو إثبات إرسال البريد الإلكتروني الصحيح في الوقت المناسب.

اختبار الوحدة

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

الثأر من تحضيرات الاختبار

لغرض اختبار وحدة الإرسال، تُستخدم التحضيرات (Fixtures) لتقديم مثال عن كيفيّة ظهور المخرجات.لمَّا كانت هذه هي رسائل بريد إلكتروني نموذجية (example emails) وليست بيانات سجل فعال (Active Record) كالتوابع الأخرى، يُحتفظ بها بصرف النظر عن التحضيرات (Fixtures) الأخرى. ويتطابق اسم المجلد الموجود في test/fixtures مع اسم المرسل، لذلك بالنسبة إلى المرسل الذي يحمل الاسم UserMailer، يجب أن يكون التحضير (Fixture) في المجلد test/fixtures/user_mailer.

إذا ولّدت مرسلًا، فلن يقوم المولّد بإنشاء بذرة لتحضيرات (Fixtures stub) إجراء المراسلة، ويجب عليك إنشاء هذه الملفات بنفسك كما هو موضّح أعلاه.

حالة الاختبار الأساسي

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

require 'test_helper'
 
class UserMailerTest < ActionMailer::TestCase
  test "invite" do
    # إنشاء البريد الإلكتروني وتخزينه من أجل التحقق منه بشكل أوسع
    email = UserMailer.create_invite('me@example.com',
                                     'friend@example.com', Time.now)
 
    # إرسال البريد الإلكتروني ثم التأكد من أنه أصبح ضمن الطابور
    assert_emails 1 do
      email.deliver_now
    end
 
    # اختبار محتوى البريد الإلكتروني المرسل من مطابقته لتوقعاتنا
    assert_equal ['me@example.com'], email.from
    assert_equal ['friend@example.com'], email.to
    assert_equal 'You have been invited by me@example.com', email.subject
    assert_equal read_fixture('invite').join, email.body.to_s
  end
end

في هذا الاختبار، أرسلنا بريدًا إلكترونيًّا وخزّنا الكائن المعادة في المتغيّر email، ثم تأكدنا من إرساله (التأكيد الأول)، ومن ثم، في الدفعة الثانية من التأكيدات، تأكدنا من أن البريد الإلكتروني يحتوي بالفعل على ما نتوقعه. واستخدمنا المساعد read_fixture لقراءة محتوى هذا الملف.

ملاحظة: سيتواجد email.body.to_s عند وجود جزء واحد فقط (شيفرة HTML أو نص)؛ فإذا كان الإرسال يوفر الإثنيّن، يمكنك اختيار التحضير (Fixture) الخاص بك على أجزاء معيّنة باستخدام email.text_part.body.to_s أو email.html_part.body.to_s.

إليك محتوى التحضير invite:

Hi friend@example.com,
 
You have been invited.
 
Cheers!

هذا هو الوقت المناسب لفهم المزيد عن كتابة الاختبارات للإجراء المراسلة الخاص بك. فالسطر ActionMailer::Base.delivery_method = :test في الملف config/environments/test.rb يضبط تابع التوصيل (delivery method) إلى وضع الاختبار (أي الوضع test) حتى لا تُسلّم الرسائل الإلكترونيّة بالفعل (هذا مفيد لتجنّب إرسال رسائل غير مرغوب فيها للمستخدمين أثناء الاختبار) ولكن بدلًا من ذلك سيضاف إلى مصفوفة (ActionMailer::Base.deliveries).

ملاحظة: يعاد تعيين المصفوفة ActionMailer::Base.deliveries تلقائيًا في الاختبارين ActionMailer::TestCase و ActionDispatch::IntegrationTest فقط؛ وإذا رغبت بالحصول على مصفوفة نظيفة خارج هذه الحالات التجريبيّة، يمكنك إعادة تعيينها يدويًا باستخدام ActionMailer::Base.deliveries.clear.

الاختبار الوظيفي واختبار النظام

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

# اختبار تكامل
require 'test_helper'
 
class UsersControllerTest < ActionDispatch::IntegrationTest
  include ActionMailer::TestHelper
 
  test "invite friend" do
    # ActionMailer::Base.deliveries التأكد من الاختلاف في
    assert_emails 1 do
      post invite_friend_url, params: { email: 'friend@example.com' }
    end
  end
end

# اختبار نظام
require 'test_helper'
 
class UsersTest < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :headless_chrome
  include ActionMailer::TestHelper
 
  test "inviting a friend" do
    visit invite_users_url
    fill_in 'Email', with: 'friend@example.com'
    assert_emails 1 do
      click_on 'Invite'
    end
  end
end

ملاحظة: تستفيد هذه الأمثلة من ActionMailer::TestHelper. أمَّا من أجل رسائل البريد الإلكتروني التي نتوقع توصيلها مباشرةً مع التابع deliver_now، يمكننا استعمال التابع assert_emails. ومن أجل رسال البريد الإلكتروني التي نتوقع توصيلها لاحقًا على أنها وظيفة فعالة (ActiveJob) مع التابع deliver_later، يمكننا استعمال التابع assert_enqueued_emails. للمزيد من المعلومات، يمكنك الاطلاع على هذا التوثيق.

اختبار الوظائف (Testing Jobs)

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

حالة اختبار أساسية

بشكل افتراضي، عند إنشاء مهمة، سيولد اختبار مرتبط أيضًا ضمن المجلد test/jobs، وهذا مثال لاختبار مهمة فوترة (billing job):

require 'test_helper'
 
class BillingJobTest < ActiveJob::TestCase
  test 'that account is charged' do
    BillingJob.perform_now(account, product)
    assert account.reload.charged_for?(product)
  end
end

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

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

التأكيدات المخصصة واختبار الوظائف داخل مكونات أخرى

تعمل الوظيفة الفعالة مع مجموعة من التأكيدات المخصّصة التي يمكن استخدامها لتقليل الاختبارات. وللحصول على قائمة كاملة بالتأكيدات المتاحة، راجع وثائق واجهة برمجة التطبيقات لـ ActiveJob::TestHelper.

من الممارسات الجيّدة التأكد من أنَّ مهامك تُضمّن بشكل صحيح أو تُنفّذ أينما استدعيتها (على سبيل المثال داخل وحدات التحكم الخاصة بك).

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

require 'test_helper'
 
class ProductTest < ActiveJob::TestCase
  test 'billing job scheduling' do
    assert_enqueued_with(job: BillingJob) do
      product.charge(account)
    end
  end
end

موارد اختبار إضافية

اختبار شيفرة برمجية معتمدة على الوقت

يوفّر ريلز توابع مساعدة مضمّنة تمكنك من التأكد من عمل تعليمات برمجيّة تعتمد على الوقت كما هو متوقّع لها.

إليك مثال باستخدام المساعد travel_to:

# لنفترض أن المستخدم مؤهل للإهداء لمدة شهر بعد تسجيله
user = User.create(name: 'Gaurish', activation_date: Date.new(2004, 10, 24))
assert_not user.applicable_for_gifting?
travel_to Date.new(2004, 11, 24) do
  assert_equal Date.new(2004, 10, 24), user.activation_date 
  # `Date.current` من (mock) أنشئ نموذج ،`travel_to` داخل الكتلة
  assert user.applicable_for_gifting?
end
assert_equal Date.new(2004, 10, 24), user.activation_date 
# فقط `travel_to`كانت التغييرات مرئية داخل الكتلة

الرجاء مراجعة توثيق الواجهة ActiveSupport::Testing::TimeHelpers البرمجة للحصول على معلومات تفصيليّة حول مساعدي الوقت المتاحين.

مصادر

• صفحة Testing Rails Applications في توثيق Ruby On Rails الرّسمي.