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.
Related
Does anyone know of a basic unit testing framework for PHP that does not require Composer in order to use it? The project's testing requirements are simple, and I expect any framework would be fine. I'd be very happy with PHPUnit if there's a way of using that without Composer, though I don't think that's possible. The alternative is to roll my own, but I'd rather not do that unless it's necessary.
I know Composer is a perfectly good system, and if the decision were mine, we'd be using it. But it's not my decision, and it has been made clear that the project leader would rather not have any unit testing if the alternative is to use Composer. That's wholly irrational, I know, but it's not a battle I have time to fight.
Actually, if you look at the installation docs, composer is not even stated as the preferred way to install PHPUnit.
The Phar version of PHPUnit can be used instead. It's easy to install and does not require composer.
To execute the tests, instead of a composer script, simply create a bash script (or cmd/powershell if you are on Windows). Although, depending on the configuration you use, it might also be as efficient to directly execute the phar.
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.
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.
I am writing a ZF application. I had some abstract parent classes in a library directory. Netbeans could generate test skeletons for the child classes no problems, and I could run the tests no problem.
Later on I decided to move the abstract parents out of the library and in to the application directory (to improve readability). I updated my application code accordingly, and it runs no problem.
However, now when I use netbeans to generate test skeletons for the child classes, it gives a fatal error saying it can not find the parent. I then constructed a test class manually and ran it from the command line, and PHPUnit gave the same error.
What do I need to do to get this pathing working correctly? In the PHPUnit bootstrap I tried adding the Application directory to the include path, and registering Application as a namespace with the Zend Autoloader. I don't think this is a recommended practice, and it failed anyhow...
I really do struggle with path issues, finding files, etc...
Any assistance is much appreciated.
OK, so I can move the classes from the library to the core code directories, and the core code finds them no problems because they conform to the standard naming conventions autoladed by ZF.
Other applications (e.g. PHPUnit) won't be able to find them though. I could get around this by setting their autoloading the same ZF. Alternatively, I could incorporate required files with require_once (which would negate the use of autoloading in the first place).
So, it seems that my best shot is to put the shared classes back in the library. My original PHPUnit bootstrap adds the library prefix to the ZF autoloader, so I'm good to go.
All-in-all, I've just learned another good use for libraries.
[EDIT:] Another Alternative...
My test classes are boostrapping Zend Application which sets up the autoloading for PHPUnit. The only drawback doing it this way is that PHPUnit (via my netbeans IDE) can't create the skeleton tests for me. I guess I'll have to live with that.
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......