Php_codesniffer: Extended Util/Common.php not found in unit tests. (3.0.1)

[louisl]

I've extended Util/Common.php for some DRY arrays and functions, this all works fine when sniffing and fixing, but when a unit test file tests a sniff that 'use's the extended Common.php it's chucking out a class not found error.

Is this something the autoloading should do? or is it something I need to alter?

$ ./vendor/bin/phpunit --debug --filter CodeIgniter4 ./tests/AllTests.php
PHPUnit 4.8.36 by Sebastian Bergmann and contributors.


Starting test 'CodeIgniter4\Tests\Arrays\ArrayDeclarationUnitTest::testSniff'.
.
Starting test 'CodeIgniter4\Tests\NamingConventions\ValidMethodNameUnitTest::testSniff'.
PHP Fatal error:  Class 'CodeIgniter4\Util\Common' not found in /Users/louislinehan/Documents/Projects/CodeIgniter4-Standard/CodeIgniter4/Sniffs/NamingConventions/ValidMethodNameSniff.php on line 98

[gsherwood]

I think I'd need to be able to look at the code and try out a phpunit run to properly diagnose the problem here.

The autoloader may be able to find the file, but possibly not in a unit test run if it has no idea what custom namespace you are using. I'd have to debug it to see if that's possible. If not, you'd need to require the file yourself.

Is this standard available in a public repo for me to try out?

[jrfnl]

I've seen similar issues with PHPCS 3.x in combination with non-sniff files (abstract base sniff classes and such) and unit tests.

It seems the PHPCS 3.x autoloader handles these files fine when it's being run normally, but does not handle this at all when in the unit test environment.

Loosely related to https://github.com/squizlabs/PHP_CodeSniffer/issues/1469

As a temporary solution until this is fixed in PHPCS, you may want to try the below (which worked for me):

Adding a custom autoload file to the ruleset using <autoload>./../MyAutoLoad.php</autoload> with something along the lines of the below as content:

<?php
/*
 * Register an autoloader.
 *
 * This autoloader is not needed for running the sniffs, however, it *is* needed
 * for running the unit tests as the PHPCS native autoloader runs into trouble there.
 */
if (defined('PHP_CODESNIFFER_IN_TESTS')) {
    spl_autoload_register(function ($class) {
        // Only try & load our own classes.
        if (stripos($class, 'MyNameSpace') !== 0) {
            return;
        }

        $file = realpath(__DIR__) . DIRECTORY_SEPARATOR . strtr($class, '\\', DIRECTORY_SEPARATOR) . '.php';

        if (file_exists($file)) {
            include_once($file);
        }
    });
}

Edit: Just to be clear & to help you get the paths working - I have this file set up in the repository root. The standard itself is contained in a subdirectory, which also contains the ruleset.xml file.
The file is loaded in the unit test scenario via a PHPUnit bootstrap (after including the PHPCS native autoloader).

[louisl]

Thanks for the quick reply.

I've only just started the unit tests so there's not many there but please take a look at the develop branch here:

https://github.com/louisl/CodeIgniter4-Standard/tree/develop

[louisl]

@jrfnl Thank you also for the quick reply and info.

[gsherwood]

I've only just started the unit tests so there's not many there but please take a look at the develop branch here:

Thanks for that. I can replicate the problem and will take a look into it.

[gsherwood]

I've pushed up a change to the way unit testing works to get the autoloader to work in the same way during unit tests runs as it does during a normal phpcs run. This means that installed paths will be added to the autoloader search paths like the main runner does, and ruleset.xml files will be parsed to find custom namespaces and to add the correct search path for them as well.

@louisl I've tried this change with your standard and it looks to be working ok.

@jrfnl It would be great if you could find some time to test this with the work you're doing on the WordPress standards, and PHPCompatibility if you are still working on those tests as well.

[jrfnl]

@gsherwood Just tested with the PHPCS 3.x compatible branch of PHPCompatibility and that removed the need for the above mentioned work-around. So yes, based on these initial tests, the change looks good to me. Thanks for that!

I'll test with WPCS later & will let you know the results for that as well.

[gsherwood]

So yes, based on these initial tests, the change looks good to me.

Great news. Thanks.

[louisl]

@gsherwood Thanks very much! Confirmed working for me too.

[gsherwood]

Confirmed working for me too.

Thanks for testing the fix for me.

[jrfnl]

@gsherwood Just letting you know: I've tested this with WPCS now as well and can confirm that this solution works for WPCS as well.

[gsherwood]

Just letting you: I've tested this with WPCS now as well and can confirm that this solution works for WPCS as well.

Thanks for testing that for me.