Rails/testing

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

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

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

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

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

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

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

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

يُنشئ  ريلز مجلّد اختبار لك حال إنشائك مشروع ريلز مستعملًا الأمر 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)، فيمكنك استخدام Headless Chrome أو Headless 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

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

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

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

لإختبار طلبات 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

ثلاثة أجزاء من Apocalypse

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

• Cookies - لملفات تعريف الارتباط التي عيّناها.
• Flash - لأي كائنات موجودة في flash.
• Session - لأي كائنات موجودة في متغيرات الجلسة.

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

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 كرؤوس:

# setting an HTTP Header

get articles_url, headers: { "Content-Type": "text/plain" } # simulate the request with custom header

# setting a CGI variable

get articles_url, headers: { "HTTP_REFERER": "http://example.com/home" } # simulate the request with custom env variable

اختبار اشعارات flash

إذا كنت تتذكر، واحد من متغيرات hash الثلاثة من Apocalypse كان 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/ريلز 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

لننفّذ رسالة flash الآن على متحكمنا، سيبدو إجراء :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/ريلز 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() إمكانيّة الوصول إلى Fixtures مقالاتنا.

فماذا عن حذف مقالة موجودة؟

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 المقالة، ويمكنك D.R.Y (عدم تكرارها بنفسك) هذه عن طريق استخدام التوابع setup وteardown التي يوفّرها ActiveSupport::Callbacks.

يجب أن يظهر اختبارنا كالتالي، تجاهل الاختبارات الأخرى في الوقت الحالي، فنحن نتركهم للإيجاز.

require 'test_helper'

class ArticlesControllerTest < ActionDispatch::IntegrationTest

 # called before every single test

 setup do

@article = articles(:one)

 end

 # called after every single test

 teardown do

# when controller is using cache it may be a good idea to reset it afterwards

ريلز.cache.clear

 end

 test "should show article" do

# Reuse the @article instance variable from setup

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)

# Reload association to fetch updated data and assert that title is updated.

@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

# helper is now reusable from any controller test case

sign_in_as users(:david)

get profile_url

assert_response :success

 end

End

اختبار المسارات

مثل كل شيء آخر في تطبيق ريلز، يمكنك اختبار مساراتك، فاختبارات المسار موجودة في  test/controllers/ أو ستكون جزء من اختبارات وحدة التحكم.

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

لمزيد من المعلومات حول تأكيدات التوجيه المتاحة في ريلز، راجع وثائق API لـ 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 ريلز 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)	يرّجع مصفوفة بكافة العناصر المحّددة بواسطة المحددّ، في النوع الثاني، يطابق أولًا العنصر الأساسي ويحاول مطابقة التعبير المحدّد على أحد أطفاله، وإذا لم يكن هنالك مطابقات، فسيرجع كلا المتغيريّن مصفوفة فارغة.

في ما يلي مثال على استخدام 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 ممدّد من ActionView::TestCase، فيمكنك الوصول إلى توابع مساعدة ريلز مثل link_to أو pluralize.

اختبار Mailer الخاص بك

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

الحفاظ على Postman في Check

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

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

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

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

هنالك جانبان لاختبار البريد الإلكتروني، اختبارات الوحدة والاختبارات الوظيفيّة، وفي اختبارات الوحدة، نشغّل Mailer بعزلة مع مدخلات متحكم بها ونقارن المخرجات مع قيمة معروفة (Fixture).

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

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

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

الثأر من Fixtures

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

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

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

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

require 'test_helper'

class UserMailerTest < ActionMailer::TestCase

 test "invite" do

# Create the email and store it for further assertions

email = UserMailer.create_invite('me@example.com',

                                 'friend@example.com', Time.now)

# Send the email, then test that it got queued

assert_emails 1 do

  email.deliver_now

end

# Test the body of the sent email contains what we expect it to

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، ثم تأكدنا من Mailer (التأكيد الأول)، ومن ثم، في الدفعة الثانية من التأكيدات، تأكدنا من أن البريد الإلكتروني يحتوي بالفعل على ما نتوقعه، ونستخدم المساعد read_fixture للقراءة في محتوى من هذا الملف.

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

هذا محتوى Fixture invite:

Hi friend@example.com,

You have been invited.

Cheers!

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

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

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

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

require 'test_helper'

class UsersControllerTest < ActionDispatch::IntegrationTest

 test "invite friend" do

assert_difference 'ActionMailer::Base.deliveries.size', +1 do

  post invite_friend_url, params: { email: 'friend@example.com' }

end

invite_email = ActionMailer::Base.deliveries.last

assert_equal "You have been invited by me@example.com", invite_email.subject

assert_equal 'friend@example.com', invite_email.to[0]

assert_match(/Hi friend@example\.com/, invite_email.body.to_s)

 end

End

اختبار الوظائف

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

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

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

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 بحيث تُنفّذ جميع المهام بشكل داخلي، وسيضمن أيضًا أن جميع المهام التي نُفّذت سابقًا والتي في الطابور مسحها قبل إجراء أي اختبار، ويمكنك أن تفترض بأمان أنه لم يُنفّذ أي مهمة بالفعل في نطاق كل اختبار.

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

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

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

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

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:

# Lets say that a user is eligible for gifting a month after they register.

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 # inside the `travel_to` block `Date.current` is mocked

 assert user.applicable_for_gifting?

end

assert_equal Date.new(2004, 10, 24), user.activation_date # The change was visible only inside the `travel_to` block.

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

انطباعات

نشجعك على المساعدة في تحسين جودة هذا الدليل.

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

قد تجد أيضًا محتوى غير مكتمل أو أشياء غير محدّثة، ويرجى إضافة أي وثائق مفقودة لـ master.

تحقق من Edge Guides أولا للتحقق مما إذا كانت المشكلات تم إصلاحها بالفعل أم لا على الفرع الرئيسي (master branch)، وتحقق من إرشادات Ruby on ريلز Guides Guidelines للأسلوب والاتفاقيات المعمول بها.

https://guides.rubyonريلز.org/testing.html