هل من روبي الاصطلاحية إضافة طريقة تأكيد () إلى فئة Ruby's Kernel؟

Question

أقوم بتوسيع فهمي لروبي من خلال ترميز ما يعادل وحدة كينت بيك xUnit في روبي.تمتلك لغة بايثون (التي يكتب بها كينت) طريقة تأكيد () في اللغة المستخدمة على نطاق واسع.روبي لا.أعتقد أنه يجب أن يكون من السهل إضافة هذا ولكن هل Kernel هو المكان المناسب لوضعه؟

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

Answer 1

لا، هذه ليست أفضل الممارسات.أفضل تشبيه للتأكيد () في روبي هو الرفع فقط

 raise "This is wrong" unless expr

ويمكنك تنفيذ الاستثناءات الخاصة بك إذا كنت تريد توفير معالجة أكثر تحديدًا للاستثناءات

Answer 2

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

• استخدام أطر عمل xUnit assert طرق التحقق من توقعات الاختبارات الخاصة بك.وهي مخصصة للاستخدام في كود الاختبار الخاص بك، وليس في كود التطبيق الخاص بك.
• تتضمن بعض اللغات مثل C أو Java أو Python assert البناء المخصص للاستخدام داخل كود برامجك، للتحقق من الافتراضات التي تضعها حول سلامتها.يتم إنشاء هذه الفحوصات داخل الكود نفسه.إنها ليست أداة مساعدة لوقت الاختبار، ولكنها أداة مساعدة لوقت التطوير.

لقد كتبت مؤخرا تأكيد_صلب:مكتبة روبي صغيرة تنفذ أداة تأكيد روبي و أيضا تدوينة في مدونتي تشرح دوافعها..يتيح لك كتابة التعبيرات في النموذج:

assert some_string != "some value"
assert clients.empty?, "Isn't the clients list empty?"

invariant "Lists with different sizes?" do
    one_variable = calculate_some_value
    other_variable = calculate_some_other_value
    one_variable > other_variable
end    

ويمكن إبطال مفعولها بذلك assert و invariant الحصول على تقييم كبيانات فارغة.يتيح لك هذا تجنب أي مشكلة في الأداء في الإنتاج.لكن لاحظ ذلك المبرمجون البراغماتيون يوصي بعدم تعطيلها.يجب عليك إلغاء تنشيطها فقط إذا كانت تؤثر بالفعل على الأداء.

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

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

Answer 3

ما سبب إضافة طريقة التأكيد إلى وحدة Kernel؟لماذا لا تستخدم فقط وحدة أخرى تسمى Assertions أو شيء ما؟

مثله:

module Assertions
  def assert(param)
    # do something with param
  end

  # define more assertions here
end

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

class Object
  include Assertions
end

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

Answer 4

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

def assert(msg=nil)
    if DEBUG
        raise msg || "Assertion failed!" unless yield
    end
end

بهذه الطريقة لن يكون هناك أي تأثير إذا قررت عدم التشغيل باستخدام مجموعة DEBUG (أو أي مفتاح آخر مناسب، لقد استخدمت Kernel.do_assert في الماضي).

Answer 5

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

ومع ذلك، فإن تأكيد بايثون (بالنسبة لي، على الأقل)، يشبه أكثر لغة C تأكيد(3).لم يتم تصميمه خصيصًا لاختبارات الوحدة، بل لالتقاط الحالات التي "لا ينبغي أن يحدث هذا أبدًا".

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