Phpunit: スカラー型のオートローダーを呼び出すassertType（）

内部タイプには、 assertType() assertInternalType()を使用してください。

それは機能しますが、なぜそれが必要なのですか？

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に同意する必要がありますが、彼のソリューションで十分なのに、なぜ別の関数を使用する必要があるのですか？ <3.5からassertTypeを使用するすでに実施されている何千もの単体テストを変更していません。 したがって、このソリューションを使用して、すべての単体テストでassertTypeをオーバーライドします。 なぜこのパスを選択したのか、もっとよく説明する価値があると思います。そうしないと、phpunitFAILを宣言する必要があります。

単一の資産化メソッドでは、2つの異なる機能を実装できません。 最初はそれが可能だと思っていたのは私の間違いでした。 これがassertInternalType()が現在存在する理由です。

単一のアサーションメソッドが2つの異なる機能を実装できない理由について説明してください。

さらに、ドキュメントは次のステートメントと矛盾します。

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

または、$ expectedを次の定数のいずれかにして、内部型を示すこともできます。

* 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（）」というセクションを参照）を使用することをお勧めします。

単一のアサーションメソッドは、あいまいなため、2つの異なる機能を実装できません。 Stringという名前のクラスがあり、 assertType("string", ...) ＃$を使用するとします。PHPUnitはどのようにしてそれが何を望んでいるのかを知ることになっていますか？

推奨事項は、まさにあなたが経験している場合に当てはまります。オートローダーを使用していて、 assertType()を使用したい場合です。 それは機能しません。

phpではクラスを整数または文字列と呼ぶことができますが、コードでは現在、無効な引数（％sはあいまいです）の例外をスローするため、クラスを文字列、整数などと呼ぶことはできません。

問題は、1208行目のclass_exists関数とinterface_exists関数でautoloadパラメーターをfalseに設定しないと、オートローダーが存在しないファイル（class.array.phpなど）をインクルードしようとし、phpエラーをスローすることです。例外の代わりに。

この変更を行うと、assertTypeをいつものように使用できるようになります。

いいえ、ありません。 他の人は、autoloadがStringクラスを自動ロードすることを期待しているので、私/ PHPUnitに怒鳴ります。

これが私のアドバイスです、それを取るか、それを残してください：

assertType()は使用しないでください。 これは非推奨になり（そのようにマークするのを忘れましたが）、最終的にはなくなります。 移行を容易にするために、現在のバージョンのPHPUnitにのみ存在します。

assertInternalType()を使用して、変数が指定された内部型を持っていることを表明します。

assertInstanceOf()を使用して、オブジェクトが指定されたタイプ（クラスまたはインターフェース）を持っていることを表明します。

非推奨の関数に問題はありませんが、移行をまったく容易にしていません。 そもそもこの例外がなかったphpunit3.4から元の機能を変更し、Stringクラスを自動ロードする人の代わりに私のコードを壊しています。 したがって、phpunit 3.5で完全に削除するか、3.4の機能に戻す必要があると思います。

落ち着いて、興奮する必要はありません。 私はセバスチャンの決定に耐えることができます、それは実際には理にかなっています、それの背後にある理由を知ることはちょうど良いことです。 そのため、将来的には他の2つの関数を使用します。 一方、assertTypeが非推奨になった場合は、以前と同じように機能し続け、将来的に削除される可能性があるため、非推奨であることを明確に文書化してください。 しかし、これはもちろん、自由ソフトウェアの方法であるため、セバスチャンの決定です。