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.
Related
I recently realized that I cannot run all my phpunit tests at once unless I use the "php artisan test", and I don't understand why. I would use the other option but I can't do coverage with that.
I assume it's somehow related to my configuration file being wrong because of a syntax change, or my directory being set wrong or something, because I can't find anything else.
The suite is found, but the suffix is not applied, whether I write it as ".php" or "Tests.php" or anything else. I know, because if I rename all my test files with Test at the end instead of Tests, then they suddently get recognized by phpunit. I also tried all numbers of directory options, like "./tests/Unit" and "./tests/Unit/*" but to no avail.
I would really appreciate some help if anyone has any idea what is happening, because it's driving me crazy. It took me a day to figure out I needed to rename my files just to make it work, and at this point I don't even want to do that unless I absolutely must, since there is this suffix feature.
I just want to understand why it does not work, and how to use it properly, in hopes of being able to learn how to use phpunit in the right way.
I can see two potential causes:
1) Your phpunit.xml may not be configured properly.
Try to change the "testsuite" and "coverage" section as shown below:
<testsuites>
<testsuite name="Unit">
<directory suffix="Test.php">./tests/Unit</directory>
</testsuite>
<testsuite name="Feature">
<directory suffix="Test.php">./tests/Feature</directory>
</testsuite>
</testsuites>
<coverage processUncoveredFiles="true">
<include>
<directory suffix=".php">./app</directory>
</include>
</coverage>
2) Make sure all your tests methods use the #test annotation in the method’s DocBlock:
/** #test */
public function your_test_method_name()
{
...
}
See: https://phpunit.readthedocs.io/en/9.5/annotations.html
As an alternative to prefixing your test method names with test, you can use the #test annotation in a method’s DocBlock to mark it as a test method.
If you don't include the docblock, make sure your test method names start with "test":
public function test_method_name()
{
...
}
See: https://phpunit.readthedocs.io/en/9.5/writing-tests-for-phpunit.html
The tests are public methods that are named test*.
Nothing worked to fix the suffix. I tried reinstalling xdebug, php, and phpstorm. I ended up just renaming the files as I said. Only working solution I could find.
I know, because if I rename all my test files with Test at the end instead of Tests, then they suddenly get recognized by phpunit.
That sounds like the default configuration for phpunit and could be a sign that your configuration file you're trying to control the behaviour with is not effective. That is, however you run Phpunit, it is without the configuration file and the path only, e.g.:
/path/to/phpunit -- /path/to/test/directory
Phpunit then will work with the default configuration - but it must find it in the working directory. So either the configuration files have a name different to the names that phpunit uses for auto-detecting or they are not in the working directory, phpunit will start without loading a configuration file and just execute what it can find in the directory with the default suffix "Test.php".
(In Phpstorm the working directory can vary when invoking Phpunit, even between runs of the same action, but that just as a comment.)
What you can do in Phpstorm: Configure the Phpunit configuration file to load. A good way to do that is to specify a default Phpunit configuration file in Settings -> PHP -> Test Frameworks in the Test Runner Section for Default configuration file.
Another thing is to specify the working directory explicitly in either the run action you already created which does not do what you want or by modifying the Phpunit run action template. Here a screenshot for the template:
A way to check the effectiveness is to make use of a bootstrap file in configuration and make it explode. Then you know whether or not something was effective.
Also PHpunit normally writes out the name of the configuration file if one is in use.
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">
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
I'm testing under Windows and the command prompt doesn't do so well with the ANSI color codes that appear by default. How can I turn off the color display when I'm using Laravel?
The file \laravel\cli\tasks\test\stub.xml is used to generate the PhpUnit configuration file for tests. (A new configuration file is generated and deleted every time you run an artisan test task.) To turn off colors, change the first line of stub.xml from <phpunit colors="true" to <phpunit colors="false" (for Laravel 3)
Update: For Laravel 4, the file is phpunit.xml and is found in the root folder. The change is still to set colors="false".
You can add colors in windows command prompt.Its great for spotting errors and success. I followed this http://softkube.com/blog/ansi-command-line-colors-under-windows/
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.