When I run tests with PhpUnit on a new package I'm creating for Laravel, it generates the file .phpunit.result.cache.
What to do with that? Do I add it to my .gitignore file or not?
I'm using PHPUnit 8.0.4
This file helps PHPUnit remember which tests previously failed, which can speed up your testing flow if you only re-run failed tests during development. This is useful for test-driven workflows in which you have configured tests to run automatically, such as on file save, and the same collection of tests is being run repeatedly.
It is also a good idea to add the cache file .phpunit.result.cache to
your .gitignore so that it does not end up being committed to your
repository.
https://laravel-news.com/tips-to-speed-up-phpunit-tests
If you would prefer not to generate the file then you can run phpunit with the --do-not-cache-result option, as pointed out by #Slack Undertow in the comments. This might be desired when running tests as part of a build pipeline, for example. Or, as #codekandis pointed out, the same option is available as the cacheResult attribute in phpunit.xml.
You can also change this file location by editing phpunit.xml:
<phpunit
...
cacheResultFile="../.temp/fs_cache/.phpunit.result.cache"
>
Or completely disable it by
<phpunit
...
cacheResult ="false"
>
Official PHPUnit explanation (I currently don't find any other useful official details).
This caching is required for certain other features to work.
You can disable it with:
<phpunit
...
cacheResult="false">
Related
Can someone explain to me what is the difference between using PHPunit configuration files named phpunit.xml.dist or phpunit.xml.
The official documentation mentions both names:
PHPUnit's XML configuration file (Appendix C) can also be used to compose a test suite. Example 5.1 shows a minimal phpunit.xml file that will add all *Test classes that are found in *Test.php files when the tests directory is recursively traversed.
with giving phpunit.xml a higher priority when loading configuration without the configuration parameter.
If phpunit.xml or phpunit.xml.dist (in that order) exist in the current working directory and --configuration is not used, the configuration will be automatically read from that file.
I did find some questions (e.g. is this .xml.dist file really required to be used) relating to the fact, that .dist files usually are used as a template (distribution) which should be copied to a version without the .dist ending to activate them (e.g. .htaccess.dist). But this seems not to be the case with PHPunit as it picks up and runs the dist file as well. Other questions (Can I use phpunit.xml for credentials and phpunit.xml.dist for testsuites?) seem to deal with other weird usage ideas about these two files.
In the Symfony world, it is mandatory for reusable bundles to include a phpunit.xml.dist file and I wonder why not a phpunit.xml file instead.
A test suite must not contain AllTests.php scripts, but must rely on the existence of a phpunit.xml.dist file.
So if anyone can shed some light onto this I would be happy ;-)
If phpunit.xml or phpunit.xml.dist (in that order) exist in the current working directory and --configuration is not used, the configuration will be automatically read from that file.
The idea behind the fallback (to phpunit.xml.dist when phpunit.xml does not exist) is that phpunit.xml.dist can be checked into version control and phpunit.xml can be ignored from version control. This allows a developer to use a custom configuration without running the risk of accidentally checking it into version control.
File .dist are versioned with git for example and you usually don't version phpunit.xml because is a configuration file of your machine.
File .dist are often configuration files which do not contain the real-world deploy-specific parameters
If there is phpunit.xml and phpunit.xml.dist phpunit takes phpunit.xml
phpunit.xml.dist It's a standard file, phpunit.xml It's a customization and aren't versioned to avoid publishing personal data
The bootstrap configuration options is commented out in the latest version of the phpunit.xml documentation:
http://www.phpunit.de/manual/current/en/appendixes.configuration.html
And indeed, it doesn't seem to be reading it in my configuration file. Why is this? How do I configure phpunit 3.6 to automatically include a bootstrap file?
It seems to me like it is extremely useful to setup your project so PHPUnit would automatically provisioned with a bootstrap file without the person running PHPUnit having to be aware of it, so they could simply do:
> phpunit
rather than:
> phpunit --bootstrap [file]
the bootstrap file should run before the tests and it is an available command line option for phpunit
--bootstrap <file>
more information on cli options:
http://www.phpunit.de/manual/current/en/textui.html#textui.clioptions
i've never used the xml config file for the bootstrap option, so i don't know why its not or no longer working, but hopefully cli works like it does for me :)
In the configuration file for PHPUnit, in version 3.4 you could include a bootstrap file as follows:
<phpunit backupGlobals="false"
backupStaticAttributes="true"
bootstrap="/path/to/bootstrap.php"
http://www.phpunit.de/manual/3.4/en/appendixes.configuration.html
But as of 3.5 this options has been commented out, so you can no longer use it:
<phpunit backupGlobals="true"
backupStaticAttributes="false"
<!--bootstrap="/path/to/bootstrap.php"-->
http://www.phpunit.de/manual/3.5/en/appendixes.configuration.html
I can't find any reference as to why this option has been disabled. I looked for release notes for PHPUnit 3.5 to see if they mentioned anything, but nothing I found mentioned bootstrap at all.
http://sebastian-bergmann.de/archives/897-PHPUnit-3.5.html
https://github.com/sebastianbergmann/phpunit/blob/3.5/README.markdown
I would still welcome a comment from anyone who knows why this options has been removed.
I am a new user of PHPUnit, and I am converting our existing tests (asserts) into the PHPUnit framework to provide a better test environment and code coverage. However, I need to know how to try to get PHPUnit working with our testing code structure.
Our project directories are similar to the following:
Application1/
CREDIT_CARD.class - Class naming convention for CREDIT_CARD
CREDIT_CARD.class.test - Automated Tests for CREDIT_CARD.class
File.php - Application File
File.php.test - Automated tests for File.php
File2.php
File2.php.test - Automated tests for File2.php
Application2/
ANOTHER_CLASS.class
ANOTHER_CLASS.class.test
DifferentFile.php - Application File
DifferentFile.php.test - Automated tests for File.php
lib/
UTIL/
SHARED_CLASS.class
SHARED_CLASS.class.test
VISUAL/
VISUAL_TOOL.class
VISUAL_TOOL.class.test
I need to know how to configure the PHPUnit tests so I can run the tests in lib/UTIL/.test (which load the class file using the setUp() method) then the lib/VC/.test, followed (if successful) by the Application1 and Application2 tests. I saw mention of a PHPUnit_xml file and a bootstrap file, but I can not find a reference template to see if these are what I need. Any help would be appreciated.
I know the documentation refers to a test.php addition to the file names, but I am hoping to not have to change our structure and naming conventions as I would like to be able to run a mix of the files until they are all converted over to the PHPUnit framework. Changing names will cause a procedure change in our company and training for the developers, which I am trying to avoid.
Thanks in advance for any assistance.
So you have files named Foo.class.test instead of the PHPUnit default FooTest.php ?
That shouldn't be a big problem as PHPUnit allows you to configure what file suffixes are to be treated as "tests". The Test.php is just the default.
Have a look at the xml config part of the docs regard test organisation
What you want is:
<testsuites>
<testsuite name="Our new shiny phpunit test Suite">
<directory suffix=".test">./sourceFolder</directory>
</testsuite>
</testsuites>
PHPUnit will then scan through the source folder including all files that end in .class.test and leaving the other files as is.
I'm trying to generate TestCase with the phpunit generator.
I'm using the following command:
phpunit --skeleton-test "Namespace\Service\ArticleService" ../library/Namespace/Service/ArticleService.php
I'd like my tests to go in /tests/Namespace/Service/ArticleServiceTest.php
Is it possible to specify such options with PHPUnit?
No, it is not possible. Open a feature request in the phpunit bug tracker on github.
The newer phpunit-skelgen (1.2.0) allows you to specify the destination file for tests, which may include path references.
Situation
We're using PHPUnit in our project and are using a phpunit.xml to ensure things like backupGlobals is turned off.
To further ensure the include path is set and autoloading is active, we also cascade our test bootstraps. That is to say, every test and alltests-suite has a require_once(__DIR__ . '/../bootstrap.php'); at the top, all the way up to the base folder level, where it obviously reads require_once(__DIR__ . '/bootstrap.php');, and the actual bootstrap file resides.
Essentially, our tests are autonomous. You can call any AllTests.php in any folder and any *Test.php by itself and they'll run with the right configuration.
Except no. 'Wait a moment.'
That's only true if we either force our developers to use phpunit --configuration=path/to/phpunit.xml or they're in the folder with the phpunit.xml (so that PHPUnit pulls it out of the current working directory when it is executed).
Occasionally, this makes it incredibly hard to determine why tests on one developer's machine are breaking and why they're running on another. It just takes forgetting that the bootstrap is not the only thing we need to have the same test environment. Keep in mind that since you couldn't forget the bootstrap if you tried, because it's in the tests themselves, forgetting other settings, especially usually-optional ones like that (if you're in the folder with the phpunit.xml, it's automatically pulled), is easy.
In fact - it's happened a few times.
Question
Is there a way I can supply which phpunit.xml to use in the test file being run, such as in our conveniently ubiquitous bootstrap file, rather than supplying it to PHPUnit beforehand, be that by command-line switch or by being in its directory ?
A cursory glance at the code suggests the answer is no - configuration well and truly seems to be loaded before test files are even pulled:
[PHPUnit/TextUI/Command.php]
...
if (isset($this->arguments['configuration'])) {
$configuration = PHPUnit_Util_Configuration::getInstance(
$this->arguments['configuration']
);
$phpunit = $configuration->getPHPUnitConfiguration();
...
That does make some sense, given that the configuration can contain test white- or blacklists.
Really, it wouldn't make sense to load test filters in the test bootstrap itself, so that's half the potential configuration out the window with, but the actual behavioural flags of PHPUnit...
[sample of part of our phpunit.xml]
<phpunit
backupGlobals="false"
backupStaticAttributes="false"
convertErrorsToExceptions="true"
convertNoticesToExceptions="true"
convertWarningsToExceptions="true"
syntaxCheck="false"
processIsolation="false"
colors="true">
...perhaps with the exception of 'colors' strikes me as something that the test itself should be able to decide on some level.
Consolation prize for...
Admittedly, right now I'd be happy just knowing if I can teach PHPUnit backupGlobals="false" from the bootstrap file, if someone knows of a way.
(If fruitless, the practical answer I'll pursue will probably be to copy the phpunit.xml into all subfolders. I'd like to avoid that solution since it creates redundant copies, and if we ever choose to change a setting... yeah, ouch!)
Direct answer: No, you cant do that.
Longer story - this kind of problem is better solved by changing the habits of developers.
Here is we do it:
All developers always run the tests from the tests root directory, which has the sole phpunit.xml with all the necessary configuration - including bootstrap, which sets up an class autoloader.
We dont have testsuites as such, tests are grouped using directories, no AllTests.php anywhere, because its not necessary. PHPUnit can take a name of directory and run all tests inside it.
Its still possible to run any single test by giving a path to it or whole testsuite (by giving path to the directory). It just has to be done from the tests root directory all the time or it wont work.
Doing it like this means giving up the freedom of starting PHPUnit from any directory, but to be honest - I dont feel like thats a loss at all.
The gains are much bigger: the amount of housekeeping code is reduced, developers cannot forget anything and results are therefore consistent.
My solution is to add a bash function
function phpu ()
{
phpunit --colors --bootstrap ~/path/to/bootstrap.php "$#";
}
Then add this to all dev .bashrc files and they can switch to using that.
We like to call them from vim so I had to add this to .vimrc: set shellcmdflag=-ic
Then you add nmap ;t :! phpu % to run the test file you're currently in.
You could update the start script (Windows bat file, or shell on *nix) and have logic in there to configure to the location of the phpunit.xml. If it is in the current directory, use it, otherwise point to the main one.
I also agree with Anti though, that all the tests should always be run, as you want to ensure that the changes, even in a directory branch, do not affect other code. Therefore, always run from the top of the tree. This also requires that the test execute quickly, but I have not really had a problem with PHPUnit on that.
Maintaining the PHPUnit.xml in each directory would be a maintenance nightmare, unless is was symbolically linked from other paths to ensure there was only one actual file.