Can we get the tests/ directory in the zip download

[Craige]

When downloading the zip from github (as Composer will do by default), the tests/ directory is absent. I assume this has to do with the build prepared for download. Unfortunately, when using php_codesniffer as a dependency in composer.json (such as when writing an internal standard with new sniffs), the tests/ directory is very valuable, if only for the AllTests.php and TestSuites.php

[gsherwood]

I added this to the export-ignore list because people specifically requested that I exclude the tests. I can't satisfy both requests. Is there any way you can use a clone, or tell composer to use a clone during development?

[Craige]

I can specify the --prefer-source flag when running composer install, but that will install all dependencies as a full clone (no zips). Furthermore, a full clone of the phpcs repository seems to take a long time for me. Long enough that it trips the 300 timeout:

     [exec]   - Installing squizlabs/php_codesniffer (2.3.0)
     [exec]     Cloning 5046b0e01c416fc2b06df961d0673c85bcdc896c
     [exec]     Failed to download squizlabs/php_codesniffer from source: The process "git clone --no-checkout 'git://github.com/squizlabs/PHP_CodeSniffer.git' '/Users/craigeleeder/Source/Symfony2-coding-standard/vendor/squizlabs/php_codesniffer' && cd '/Users/craigeleeder/Source/Symfony2-coding-standard/vendor/squizlabs/php_codesniffer' && git remote add composer 'git://github.com/squizlabs/PHP_CodeSniffer.git' && git fetch composer" exceeded the timeout of 300 seconds.

[Konafets]

You could maintain two installations of PHPCS.

1. The first one is a clone of PHPCS.
2. The 2nd one is a composer installation with your custom standard inside.

As long vendor/bin/ is in your $PATH you will get the right installation of PHPCS for production use. For testing purpose just use the binary from the clone.

In next step you symlinking your custom standard into the clone of PHPCS.
With this setup you are able to execute your custom sniffs within both installations and you are able to make changes on the custom standard which are covered by tests and they are immediately available in the production installation.

[Craige]

@Konafets You may be misunderstanding my requirements.

Right now, I have php_codesniffer and phpunit as dependencies in the repository for this standard. Upon installation, I run:

$ ./bin/phpcs --config-set installed_paths `pwd`/src # My standard is located under ./src

This way, I can run phpunit --filter=MyStandard_* vendor/squizlabs/php_codesniffer/tests/AllTests.php

I'm really only concerning myself with development of this standard as this use-case. Using the standard in production isn't a problem, as I don't have to worry about the /tests directory for testing.

[orlitzky]

I came to ask for the same thing. I'm working on the CodeSniffer package for Gentoo, and when our users install a package, they have the ability to run the test suite before proceeding with the installation (in case something is screwed up). The tests work really well out of the box (thank you!) but they aren't present in the tarball that we fetch.

I can make our package fetch from git, but we try to avoid it. Cloning from git prevents us from using our mirror infrastructure, and prevents us from signing a package manifest containing the SHA-whatever hash of the tarball for verification. It also wastes a ton of time/space on the users machines since they get the whole project history instead of just the release that they want.

So, if this decision was arrived at democratically, please count my vote for shipping the tests =)

[orlitzky]

I committed this with the test suite disabled (RESTRICT=test):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=478531c6053a110779bd4bbc8adcd165c047a339

But it would Just Work if the tests directory were there. If it ever comes back I can remove that line and you'll get a lot more people automatically exercising your test suite.

[gsherwood]

I've added the tests dir back into the 3.x version only. The PHAR files are already bigger there as well, and the .gitattributes wasn't even working properly due to file paths being changed. If nobody complains about the tests being in there again, then I guess I'lll leave it in. If someone eventually finds a good reason to remove them again, I'll consider removing them.

[roborourke]

@gsherwood would it be possible to put the tests in a separate repo and have them as a dev requirement? Best of both worlds so only those who need them can require them in their own custom sniff repos.

[gsherwood]

would it be possible to put the tests in a separate repo and have them as a dev requirement?

Im sure it is possible, but then I wouldn't be able to run them from a clone unless I use a submodule. I'd also have to change the way tests are discovered and run so they don't live inside the standard's directory, which isn't something I want to do.