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을 재정의할 것입니다. 왜 이 경로를 선택했는지 더 잘 설명할 가치가 있다고 생각합니다. 그렇지 않으면 phpunit FAIL을 선언해야 합니다.

단일 자산화 방법은 두 가지 다른 기능을 구현할 수 없습니다. 처음에 그것이 가능하다고 가정한 것은 나의 실수였습니다. 이것이 지금 assertInternalType() 이 존재하는 이유입니다.

단일 어설션 메서드가 두 가지 다른 기능을 구현할 수 없는 이유에 대한 설명을 제공하십시오.

또한 귀하의 문서는 다음 진술과 모순됩니다.

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()" 섹션 참조)을 사용하는 것이 좋습니다.

단일 어설션 메서드는 모호하기 때문에 두 가지 다른 기능을 구현할 수 없습니다. String 라는 클래스가 있고 assertType("string", ...) 를 사용한다고 가정해 보겠습니다. PHPUnit이 원하는 것을 어떻게 알 수 있을까요?

권장 사항은 현재 겪고 있는 경우와 정확히 일치합니다. 자동 로더를 사용 중이고 assertType() 를 사용하려고 합니다. 작동하지 않습니다.

PHP는 클래스를 정수 또는 문자열이라고 하는 것을 허용하지만 현재 코드에서는 유효하지 않은 인수(%s는 모호함) 예외를 throw하므로 클래스를 문자열, 정수 등으로 호출하는 것을 허용하지 않습니다.

문제는 1208행의 class_exists 및 interface_exists 함수에서 autoload 매개변수를 false로 설정하지 않으면 자동 로더가 존재하지 않는 파일(예: class.array.php)을 포함하려고 시도하고 PHP 오류가 발생한다는 것입니다. 예외 대신.

이렇게 수정하면 assertType이 항상 그랬던 것처럼 사용할 수 있습니다.

아니, 그렇지 않습니다. 왜냐하면 자동 로드가 String 클래스를 자동 로드할 것으로 기대하기 때문에 다른 사람들이 나/PHPUnit에게 소리를 지르기 때문입니다.

여기 내 조언이 있습니다. 가져가거나 놔두십시오.

assertType() 를 사용하지 마십시오. 더 이상 사용되지 않으며(그렇게 표시하는 것을 잊었지만) 결국 사라질 것입니다. 마이그레이션을 쉽게 하기 위해 현재 버전의 PHPUnit에만 존재합니다.

assertInternalType() 를 사용하여 변수에 지정된 내부 유형이 있는지 확인합니다.

assertInstanceOf() 를 사용하여 개체에 지정된 유형(클래스 또는 인터페이스)이 있는지 확인합니다.

더 이상 사용되지 않는 기능에는 문제가 없지만 마이그레이션이 전혀 용이하지 않습니다. 처음에는 이 예외가 없었고 이제 String 클래스를 자동 로드하는 사람 대신 내 코드를 중단하는 phpunit 3.4에서 원래 기능을 변경했습니다. 따라서 phpunit 3.5에서 완전히 제거하거나 3.4 기능으로 되돌려야 한다고 생각합니다.

진정해, 흥분할 필요 없어. 나는 Sebastian의 결정에 따라 살 수 있습니다. 실제로 이해가 갑니다. 그 이유를 아는 것이 좋습니다. 그래서 나는 앞으로 다른 두 가지 기능을 사용할 것입니다. 반면에 assertType이 더 이상 사용되지 않는 경우 이전과 같이 계속 작동하고 향후 언젠가 제거될 수 있으므로 더 이상 사용되지 않음을 명확하게 문서화하십시오. 그러나 이것은 자유 소프트웨어의 방식이기 때문에 물론 Sebastian의 결정입니다.