PHPUnit command-line. Configuring --bootstrap - php

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.

Related

How to generate Tests in tests/ directory in PhpStorm?

PhpStorm has some sort of weird behaviour that is driving me crazy. I've got my project setup to have a source and a test directory. The source directory should be for productive code, while the test directory should contain all the phpunit tests.
In those directories, the folder structure is mirrored - if I have a class \foo\Bar,
then there is
src/foo/Bar.php and test/foo/BarTest.php.
I've marked src/ and test/ as source and test directory in PhpStorm, however, every time I want to create a new test suite for a class, PhpStorm defaults to put the test class into the src/ directory next to the class under test.
It's possible to change that, however it get's more annoying when that same directory in test/ does not exist yet. Instead of creating it, PhpStorm will just reject to create that test suite for me.
Maybe I am misunderstanding the concept behind test management in PhpStorm quite a bit - because it just can't be that bad user experience.
Is there something I am doing wrong, or something that I can configure to make the situation less painful?
You are doing nothing wrong. It just does not work this way -- devs coded it to behave in a way it is right now.
Originally IDE used PHPUnit's ability to generate test classes (back then such functionality was part of actual PHPUnit). Then PHPUnit creator(s) have moved this functionality into separate package (phpunit-skelgen) .. and you had to install it manually/separately. Then devs decided to drop phpunit-skelgen support completely and implemented current implementation (which is also more in line with similar routines in other IDEs built on IDEA platform/technologies supported by those IDEs).
There are quite few tickets about changing such behaviour to the same as you described/desired .. but so far it does not look like it's in their priority list...
https://youtrack.jetbrains.com/issue/WI-2850
https://youtrack.jetbrains.com/issue/WI-24358
https://youtrack.jetbrains.com/issue/WI-21890
Subscribe to those tickets (star/vote/comment) to get notified on progress.
As of release 2016.3 PHPStorm now takes places tests in the specified tests directory, providing exactly what you ask for in your question.

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.

How to consolidate ZF2 unit/application module tests into a single call?

I'm following the ZF2 convention of storing tests in the modules and everything is working fine when tests are run from within each module. What I would like to do is have a root level phpunit.xml that calls the individual module tests and consolidates them to produce code coverage data and other metrics.
The problem is that each individual test suite is bootstrapped within the modular phpunit.xml files. The only way I'm aware of doing things is to configure the bootstrap in each phpunit.xml file which obviously doesn't get picked up when running tests from root as individual xml files are ignored.
So my question is: is there a way for a root-level phpunit.xml file to read individual phpunit.xml and bootstrap files from modules, a kind of phpunit config inheritance if you will? I could go down the route of writing this in Phing or a CI script but I'd like it done quick and dirty while in development and this solution still wouldn't produce a consolidated code report.
Basically, I want something like this, but rather than run the tests, I want it to run the individual phpunit.xml files within each module. Is this possible?
<?xml version="1.0" encoding="UTF-8"?>
<phpunit>
<testsuites>
<testsuite name="Site Tests">
<directory>./module/Application/test/ApplicationTest</directory>
<directory>./module/User/test/UserTest</directory>
</testsuite>
</testsuites>
</phpunit>
Update
The aim is to have code metrics generated by PHPUnit that give a project overview, not a modular specific overview. I appreciate the scripts in the answers will run the unit tests on a per-module basis but this is not what I'm looking for. I understand that this may be a limitation as far as PHPUnit is concerned. I will look into this over the next few days and try and find a solution as it seems like something that would be useful in a lot of projects that deal with custom modules.
Update 2
Robert Basic came up with a script that creates a directory structure with the module reports inside and it works great but would be nice to have it running within PHPUnit with the proper metrics reporting.
https://gist.github.com/robertbasic/5329789
If you are using Linux you could create a simple script. Not exactly the solution you wanted, but could help none the less:
#!/bin/sh
modDir=$(pwd)
for i in *; do
if [[ -d $i/test ]]; then
cd $i/test
phpunit
cd $modDir
fi
done
You could just drop that in to a runtests.sh file in the module directory.
Just a thought :)
Having previously discussed this on irc with various people I'm pretty sure you can't, you need to write a script to loop through the modules and run them on a module by module basis.

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