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
• ريلز::Generators::TestCase

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

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

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

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

$ bin/ريلز 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/ريلز 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/ريلز test test/models/article_test.rb:6 # run specific test and line

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

$ bin/ريلز test test/controllers # run all tests from specific directory

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

يمكنك الاطلاع على التوثيق الخاصّ بمنفّذ الاختبار كما يأتي:

$ bin/ريلز 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: ريلز, pride

Usage: bin/ريلز test [options] [files or directories]

You can run a single test by appending a line number to a filename:

   bin/ريلز test test/models/user_test.rb:27

You can run multiple files and directories at the same time:

   bin/ريلز test test/controllers test/integration/login_test.rb

By default test failures and errors are reported inline during a run.

ريلز 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/ريلز db:migrate).    

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

حقيقة الـ Fixtures

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

ما هي الـ Fixtures؟

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

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

بإمكانك إيجاد الـ Fixtures في المجلّد test/fixtures. عندما تنفّذ الأمر ريلز generate model لإنشاء نموذج جديد، يُنشئ ريلز بذور Fixtures في هذا المجلّد.

YAML

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

هذه عيّنة ملفّ YAML Fixture

# 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 باستخدام المحرف # في العمود الأوّل.

إذا كنت تستخدم الارتباطات، يمكنك تعريف عقدة مرجعيّة بين كلّ Fixtures مختلفتين. إليك مثالًا بارتباط belongs_to/has_many.

# In fixtures/categories.yml

about:

 name: About

# In fixtures/articles.yml

first:

 title: Welcome to ريلز!

 body: Hello world!

 category: about

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

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

ERB موجود

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

<% 1000.times do |n| %>

user_<%= n %>:

 username: <%= "user#{n}" %>

 email: <%= "user#{n}@example.com" %>

<% end %>

Fixtures عند العمل

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

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

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

Fixtures هي كائنات Active Record

إن Fixtures هي أمثلة لـ Active Record، وكما ذكرنا في النقطة الثالثة أعلاه، يمكنك الوصول إلى الكائن مباشرةً لأنه متوفّر تلقائيًا كتابع حيث أن نطاقه محلي هو حالة الاختبار، فمثلًا:

# this will return the User object for the fixture named david

users(:david)

# this will return the property for david called id

users(:david).id

# one can also access methods available on the User class

david = users(:david)

david.call(david.partner)

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

# this will return an array containing the fixtures david and steve

users(:david, :steve)

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

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

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

$ bin/ريلز 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/ريلز 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 ومتصفح كروم وشاشة بحجم 1400x1400، ويوضح القسم التالي كيفيّة تغيير الإعدادات الإفتراضيّة.

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

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

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

إذا رغبّت بتغيير الإعدادات الافتراضيّة، فيمكنك تغيير مشغّل نظام الاختبارات، فلنفترض أنك ترغب في تغيير برنامج التشغيل من Selenium إلى Poltergeist، فيجب عليك أولا إضافة poltergeist gem إلى 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، فسيُنشئ هيكل اختبار للنظام تلقائيًا لك، وإذا لم تستخدم مولد scaffold، فابدأ بإنشاء هيكل اختبار للنظام.

$ bin/ريلز 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/ريلز test:system

ملاحظة: بشكل افتراضي، لن يشغّل bin/ريلز test نظام الاختبارات الخاصة بك، فتأكد من تشغيل bin/ريلز 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 لإنشاء مقال جديد في قاعدة البيانات.

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

الغوص أكثر

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

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

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

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

$ bin/ريلز 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 مع بعض المساعدين الإضافيين المتوفرين عند كتابة اختبارات التكامل، دعونا نقدم لك باختصار الفئات الثلاثة التي يجب أن نختار منهم:

للتعامل مع عدّاء اختبار التكامل، راجع ActionDispatch::Integration::Runner.

عند تنفيذ الطلبات، سيتاح لنا ActionDispatch::Integration::RequestHelpers للاستخدام.

إذا أردت تعديل الجلسة، أو حالة اختبار التكامل، فألقي نظّرة على ActionDispatch::Integration::Session لمساعدتك.

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

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

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

$ bin/ريلز generate integration_test blog_flow

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

invoke  test_unit

create test/integration/blog_flow_test.rb

الآن، دعونا نفتح هذا الملف ونكتب تأكيدنا الأول:

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! إذا كنت تخطط لتقديم طلبات لاحقة بعد إجراء إعادة التوجيه.

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

الغوص أكثر

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

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

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

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

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

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

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

$ bin/ريلز 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.

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

$ bin/ريلز 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: 'ريلز is awesome!', title: 'Hello ريلز' } }

 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