Phpunit: assertType() menjalankan autoloader untuk tipe skalar

Dibuat pada 23 Nov 2010  ·  10Komentar  ·  Sumber: sebastianbergmann/phpunit

Saat menggunakan assertType() untuk memeriksa apakah suatu nilai adalah array atau nilai skalar, autoloader dipanggil (sebagai efek samping dari penggunaan class_exists()). Akan lebih baik untuk memeriksa apakah parameter string tipe yang diharapkan cocok dengan "array" atau tipe skalar terlebih dahulu.

Contoh:

$this->assertType('array', array());

Diharapkan: benar, tanpa menggunakan autoloader
Aktual: benar, menjalankan autoloader untuk kelas bernama "array"

Komentar yang paling membantu

Harap gunakan assertInternalType() sebagai ganti assertType() untuk tipe internal.

Semua 10 komentar

Harap gunakan assertInternalType() sebagai ganti assertType() untuk tipe internal.

Itu berhasil, tetapi mengapa itu perlu?

Berikut adalah kode dari 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)
                );
            }

Tampak bagi saya bahwa PHPUnit_Util_Type::isType sudah menguji apakah tipenya adalah tipe internal, jadi yang harus Anda ubah hanyalah ini:

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

untuk menonaktifkan autoloader untuk tipe internal. Apa yang saya lewatkan?

Saya harus setuju dengan arnoschaefer, mengapa Anda mengharuskan kami menggunakan fungsi yang berbeda ketika solusinya cukup? Saya tidak mengubah ribuan unit test yang sudah ada yang menggunakan assertType dari <3.5. Jadi saya akan mengganti assertType untuk semua pengujian unit saya dengan solusi ini. Saya pikir kami pantas mendapatkan penjelasan yang lebih baik mengapa Anda memilih jalur ini jika tidak, saya harus mendeklarasikan phpunit FAIL.

Metode aset tunggal tidak dapat mengimplementasikan dua fungsi yang berbeda. Adalah kesalahan saya untuk berasumsi pada awalnya bahwa itu mungkin. Inilah mengapa assertInternalType() ada sekarang.

Tolong berikan penjelasan mengapa metode pernyataan tunggal tidak dapat mengimplementasikan dua fungsi yang berbeda?

Selain itu, dokumentasi Anda bertentangan dengan pernyataan ini:

http://www.phpunit.de/manual/3.5/en/api.html#api.assert.assertType :

Atau, $expected dapat menjadi salah satu dari konstanta ini untuk menunjukkan tipe internal:

* 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")

Catatan Anda di bawah ini hanya "merekomendasikan" bahwa assertInternalType harus digunakan dan tidak diperlukan:

Catatan

Direkomendasikan untuk menggunakan assertInternalType (lihat bagian yang disebut "assertInternalType()") sebagai gantinya untuk memeriksa tipe internal.

Metode pernyataan tunggal tidak dapat mengimplementasikan dua fungsi yang berbeda karena keduanya ambigu. Katakanlah Anda memiliki kelas bernama String dan menggunakan assertType("string", ...) -- bagaimana PHPUnit dapat mengetahui apa yang Anda inginkan?

Rekomendasinya persis untuk kasus yang Anda alami: Anda menggunakan autoloader dan ingin menggunakan assertType() . Itu tidak bekerja.

Meskipun php mengizinkan sebuah kelas untuk disebut integer atau string, kode Anda saat ini tidak mengizinkan sebuah kelas untuk disebut string, integer, dll karena akan memunculkan pengecualian argumen yang tidak valid (%s ambigu).

Masalahnya adalah jika Anda tidak menyetel parameter autoload ke false dalam fungsi class_exists dan interface_exists pada baris 1208, autoloader akan mencoba memasukkan file yang tidak ada (misalnya class.array.php) dan memunculkan kesalahan php bukannya pengecualian.

Membuat modifikasi ini akan memungkinkan assertType untuk digunakan seperti biasanya.

Tidak, tidak akan. Karena kemudian orang lain akan meneriaki saya / PHPUnit karena mereka mengharapkan autoload untuk autoload kelas String mereka.

Ini saran saya, ambil atau tinggalkan:

Jangan gunakan assertType() . Itu sudah usang (walaupun saya lupa menandainya) dan pada akhirnya akan hilang. Itu hanya ada di versi PHPUnit saat ini untuk memudahkan migrasi.

Gunakan assertInternalType() untuk menegaskan bahwa variabel memiliki tipe internal yang ditentukan.

Gunakan assertInstanceOf() untuk menegaskan bahwa suatu objek memiliki tipe tertentu (kelas atau antarmuka).

Saya tidak punya masalah dengan fungsi yang tidak digunakan lagi tetapi Anda tidak mengurangi migrasi sama sekali. Anda telah mengubah fungsionalitas asli dari phpunit 3.4 yang tidak memiliki pengecualian ini sejak awal dan sekarang melanggar kode saya alih-alih orang yang memuat kelas String secara otomatis. Jadi saya pikir Anda harus menghapusnya sepenuhnya di phpunit 3.5 atau mengembalikannya ke fungsionalitas 3.4.

Tenang saja, tidak perlu heboh. I untuk satu dapat hidup dengan keputusan Sebastian, sebenarnya masuk akal, hanya baik untuk mengetahui alasan di balik itu. Jadi saya akan menggunakan dua fungsi lainnya di masa mendatang. Di sisi lain, jika assertType tidak digunakan lagi, mengapa tidak membuatnya tetap berfungsi seperti sebelumnya, dan dengan jelas mendokumentasikan bahwa itu tidak digunakan lagi, dapat dihapus di masa mendatang. Tapi itu tentu saja keputusan Sebastian, karena ini adalah cara perangkat lunak bebas.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

greg0ire picture greg0ire  ·  4Komentar

AnmSaiful picture AnmSaiful  ·  4Komentar

keradus picture keradus  ·  3Komentar

sebastianbergmann picture sebastianbergmann  ·  3Komentar

joubertredrat picture joubertredrat  ·  4Komentar