PHPUnit --no-coverage option to overwrite config file - php

I use PHPUnit to test my projects, using a phpunit.xml.dist config file.
The default configuration for all my projects is set to generate html code coverage reports.
Is there anyway I can run the phpunit command at a given time without generating the code coverage reports without having to change the config file?
This would be something like a --no-coverage option.

As noted by Gonçalo Queirós in this answer, the --no-coverage option is supported since version 4.8.

I couldn't find anything from the documentation to reference any sort of functionality that would provide the option to be a toggle.
You could point PHPunit to a second phpunit.xml that doesn't have the code coverage
You can see this very question being asked prior.
Is there a way to disable code coverage in PHPUnit for a single test?

Related

PHPUnit command-line. Configuring --bootstrap

Sorry for the basic nature of this question but I've tried figuring this out through phpunit docs and online searching but can't piece it together.
I have a number of php classes that I would like to test against via a phpunit cli interface script (windows box) but I'm stuck on a very basic thing.
my test subjects are, e.g., c:\src\classes and test files are here, c:\src\tests
I can run individually by doing the following:
$> phpunit --bootstrap c:\src\classes\<name of class subject> c:\src\tests\<name of test file>
what I want to be able to is:
$> phpunit --bootstrap <something that registers multiple class subjects> c:\src\tests
so it would run against all tests in the c:\src\tests directory.
I've found references to the phpunit.xml that would be read prior to each phunit execution which I assume is where I could provide information about where the classes are for the tests, but all references that I've found to this has been unhelpful and have sent me down a couple of rat holes. Could someone point me to documentation that shows this configuration in plain black and white?
thanks!
What you should pass to --bootstrap is the path of a PHP script that registers an autoloader that is responsible for loading (only) your classes.
Such an autoloader can be created using a tool like phpab. Composer also generates an autoloader for you when you use it to manage the dependencies of your project.

Use two composer autoloaders in phing to run phpunit

I have a situation, that all app code comes from one source already compiled and in read only access. I need to run tests, but code that comes to me do not have phpunit installed.
Would it be possible to pass 2 autoloaders to phpunit using phing? One with app dependencies and other with phpunit?
phpunit is a command line program that already comes with it's own autoloading, and it only needs the directory with test classes (applying it's own autodetection/autoloading to them), and a bootstrap script which allows to instantiate all the classes that at some point need to be tested.
So the answer is "yes, expect to be able to use two autoloaders", but there most certainly is no need to fiddle with the autoloader coming with PHPUnit.

phpunit test for latest dependencies

BACKGROUND
I am working on a PHP project with unit testing and Travis CI. (It is Source Speak.)
This project "depends" on Twitter Bootstrap. In other words it includes the line:
//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css
I can find out the latest release of bootstrap by querying:
https://api.github.com/repos/twbs/bootstrap/releases
QUESTION
How do I add a unit test that confirms that all URLs in the project like //netdna.bootstrapcdn.com/bootstrap/*/css/bootstrap.min.css are using the latest version of Bootstrap?
-and-
Is there any documented best practice that says I shouldn't be doing this?
Edit: Yes, bower is a good solution as well and is probably preferable if you are already using bower for something else.
I would write a shell script that curl's the version from the url and then downloads it from the version specified in the original curl call. There is no documented best practice that says you shouldn't be doing this, but I would probably add the bootstrap css file to version control so that you can track when you updated bootstrap and easily downgrade if a new version breaks anything.
If you need any help with the shell script let me know with a comment and I can show you one.

How to bundle PHPUnit with my code?

I would like to:
Run tests with PHPUnit regardless of my environment (and if PHPUnit or PEAR is installed or not)
Show test results on screen if possible
How can I do this? I tried downloading the code here and including Autoload.php but it still have some dependencies. Maybe there's some better approach for this than trying to bundle it with my code...?
To include PHPUnit in your projects source files I'd suggest following the guide:
Using PHPUnit From a Git Checkout from the PHPUnit Contributung section.
It tells you about all the packages you need to install and shows you show to build a runner/wrapper script for the phpunit executable.
#!/bin/bash
php -d include_path='.:../phpunit/:../dbunit/:../php-code-coverage/:../php-file-iterator/:../php-invoker/:../php-text-template/:../php-timer:../php-token-stream:../phpunit-mock-objects/:../phpunit-selenium/:../phpunit-story/:/usr/local/lib/php' ../phpunit/phpunit.php $*
You can adapt the path to your need or if you want to wrap it in another script you can also use phpunit somewhat programmatically by
require '/path/to/phpunit/PHPUnit/Autoload.php';
PHPUnit_TextUI_Command::main();
This assumes that you ether have a phpunit.xml.dist file or that you use the proper cli parameters when calling your wrapper script.
You can also use the pear packages and unpack all the stable versions instead of working from the git checkout to save some disk and repo space. The wrapper script and all the include path work is the same :)
Related SO questions:
PHP - Is there a portable version of PHPUnit?
PHPUNIT without installation
The dependencies will be dependent on what add-ons you're using, PHPUnit by itself should be self contained. Since there's no particularly consistent package management solution for PHP (and you've eliminated the most viable options aside from wheel reinvention), your best bet would be to include the files in the source tree separate from the application code. Creating a sibling directory from whatever your APPLICATION_ROOT or similar would be that is named "test" and that has a "lib" or similar directory full of PHPUnit and any dependencies you need for it would likely be a good plan. There should be no overlapping and a one way dependency from the test dir to the main application source.
I'm assuming you're looking for a healthcheck automated test page, so you could create the single page that includes what is needed from that test directory. Ideally if you have the web directory which exposes your static resources you could have the PHP file that is in charge of loading the Front Controller for your application by including the application folder from outside of the document root, and then a second file that loads the test suite. That would allow your application directory to remain focused on the application code itself, the test directory to house your testing code, and then the 2 small include files which are in charge of loading the codebases (with any kind of shared constant definitions, etc. also extracted and kept DRY).
There is a consistent package management solution for PHP - http://getComposer.org. It also now has a means to install PHPunit in the usual composer style, http://packagist.org/packages/phpunit/phpunit
With the software installed, it will put the phpunit command line script into the local 'bin/' directory, so you can call it, though you will likely want to have a shell script that also sets the configuration file it will use.
The usual setup is a tests/ subdirectory with the hierarchy of PHPunit-extending classes that run the actual tests.

Can I package PHPUnit as a phar?

I would like to package PHPUnit and various other test dependencies into a phar and put that into svn. This way I can run phpunit on any client machine without needing pear. Can this be done?
Current status:
Work on a phpunit.phar has started in the phpunit repo but the generated phar is not stable and not feature complete.
If it gets there there will be official releases
Original answer:
If you can I'll give you 500 rep, a 100 Bucks and my first born.. well no.. just the first two.
To be serious:
I've nagged the creator of PHPUnit about this topic on at least 3 conferences now and well.. it doesn't seem like it's possible.
There are a couple of issues with that. First off PHPUnit spawns new php processes for test isolation. The problem with this is that a phar can't tell which php executable called it. So if you start phpunit with a custom compiled version it would use the "default" php installed to spawn the isolated tests.
Secondly as far as i know and have been told it's not possible to put static files like images and css in a phar. Which makes generating code coverage a lot harder. That would require some work on that part.
There are other issues i can't recall exactly recall right having to do with xDebug being able to provide code coverage for phars (and phpunit relying on not generating overage for it's own code and so) and others things.
There once was a phar but from my understanding that just doesn't work out with the current state of phpunit and never really worked completly.
I'm not saying it can't be done just that various people already have given up on creating a phpunit.phar including the guy how develops it. (That is just my impression, i of course can't speak for Sebastian here and might be completely wrong, take this as a little disclaimer)
Putting PHPUnit into SVN
You don't have to build a .phar to do so!
For my company I maintain a svnd version of PHPUnit. It's not the recommended way of using it but it works without much issues!
Follow the "using from a git checkout" instructions on the phpunit github site. You then need to put those files into your php include path and it works.
My suggestion would be to create a custom phpunit.sh that modifies the include path and then calls the original phpunit.sh passing along all arguments. It's a little bit of work but it works quite well and it is a hell of a lot easier than creating a phar archive :)
From the new PHPUnit page:
We distribute a PHP Archive (PHAR) that contains everything you need in order to use PHPUnit. Simply download it from here, make it executable, and put it into your $PATH, for instance......

Categories