Phpunit: assertType () استدعاء أداة التحميل التلقائي للأنواع العددية

الرجاء استخدام assertInternalType() بدلاً من assertType() للأنواع الداخلية.

هذا يعمل ، ولكن لماذا هذا ضروري؟

ها هو كود assertType:

public static function assertType($expected, $actual, $message = '')
{
    if (is_string($expected)) {
        if (PHPUnit_Util_Type::isType($expected)) {
            if (class_exists($expected) || interface_exists($expected)) {
                throw new InvalidArgumentException(
                  sprintf('"%s" is ambigious', $expected)
                );
            }

يبدو لي أن PHPUnit_Util_Type :: isType يختبر بالفعل ما إذا كان النوع داخليًا ، لذلك كل ما عليك تغييره هو:

            if (class_exists($expected, false) || interface_exists($expected, false)) {

لتعطيل أداة التحميل التلقائي للأنواع الداخلية. ماذا ينقصني؟

يجب أن أتفق مع arnoschaefer ، لماذا تطلب منا استخدام وظيفة مختلفة عندما يكون حله كافياً؟ أنا لا أقوم بتغيير الآلاف من اختبارات الوحدة الموجودة بالفعل والتي تستخدم assertType من <3.5. لذلك سوف أتجاوز assertType لجميع اختبارات الوحدة الخاصة بي بهذا الحل. أعتقد أننا نستحق شرحًا أفضل لماذا اخترت هذا المسار وإلا سأضطر إلى إعلان phpunit FAIL.

لا يمكن لطريقة الأصل الواحدة تنفيذ الوظيفتين المختلفتين. كان خطئي أن أفترض في البداية أن ذلك ممكن. هذا هو سبب وجود assertInternalType() الآن.

يرجى تقديم تفسير لماذا لا تستطيع طريقة تأكيد واحدة تنفيذ الوظيفتين المختلفتين؟

بالإضافة إلى ذلك ، فإن وثائقك تتعارض مع هذا البيان:

http://www.phpunit.de/manual/3.5/en/api.html#api.assert.assert النوع :

بدلاً من ذلك ، يمكن أن يكون $ متوقع أحد هذه الثوابت للإشارة إلى نوع داخلي:

* PHPUnit_Framework_Constraint_IsType::TYPE_ARRAY ("array")
* PHPUnit_Framework_Constraint_IsType::TYPE_BOOL ("bool")
* PHPUnit_Framework_Constraint_IsType::TYPE_FLOAT ("float")
* PHPUnit_Framework_Constraint_IsType::TYPE_INT ("int")
* PHPUnit_Framework_Constraint_IsType::TYPE_NULL ("null")
* PHPUnit_Framework_Constraint_IsType::TYPE_NUMERIC ("numeric")
* PHPUnit_Framework_Constraint_IsType::TYPE_OBJECT ("object")
* PHPUnit_Framework_Constraint_IsType::TYPE_RESOURCE ("resource")
* PHPUnit_Framework_Constraint_IsType::TYPE_STRING ("string")

ملاحظتك أدناه "توصي" فقط باستخدام assertInternalType وأنها ليست مطلوبة:

ملحوظة

يوصى باستخدام assertInternalType (راجع القسم المسمى “assertInternalType ()”) بدلاً من ذلك للتحقق من الأنواع الداخلية.

لا يمكن لطريقة التأكيد المنفردة تنفيذ الوظيفتين المختلفتين لأنهما غامضتان. لنفترض أن لديك فئة باسم String واستخدم assertType("string", ...) - كيف من المفترض أن تعرف PHPUnit ما تريده؟

التوصية مناسبة تمامًا للحالة التي تواجهها: أنت تستخدم أداة التحميل التلقائي وتريد استخدام assertType() . هذا الشىء لا يعمل.

بينما يسمح php للفئة بأن تسمى عددًا صحيحًا أو سلسلة ، فإن الكود الخاص بك حاليًا لا يسمح للفئة بأن تسمى سلسلة ، أو عدد صحيح ، إلخ لأنها ستطرح استثناءً غير صالح (٪ s غامض).

تكمن المشكلة في أنك إذا لم تقم بتعيين معلمة التحميل التلقائي على خطأ في الدالتين class_exists و interface_exists في السطر 1208 ، فإن أداة التحميل التلقائي ستحاول تضمين ملف غير موجود (مثل class.array.php) وإلقاء خطأ php بدلا من استثناء.

سيسمح إجراء هذا التعديل باستخدام assertType كما كان دائمًا.

لا ، لن تفعل ذلك. لأنه بعد ذلك سوف يصرخ الآخرون في وجهي / PHPUnit لأنهم يتوقعون أن يقوم التحميل التلقائي بالتحميل التلقائي لفصلهم String .

ها هي نصيحتي ، خذها أو اتركها:

لا تستخدم assertType() . تم إهماله (على الرغم من أنني نسيت وضع علامة عليه على هذا النحو) وسيختفي في النهاية. إنه موجود فقط في الإصدارات الحالية من PHPUnit لتسهيل الترحيل.

استخدم assertInternalType() لتأكيد أن متغيرًا له نوع داخلي محدد.

استخدم assertInstanceOf() لتأكيد أن الكائن له نوع محدد (فئة أو واجهة).

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

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