I ran phpunit with code coverage in order to see which ones of my classes are less tested.
I arbitrarily excluded some folders such as DataFixtures (Doctrine fixtures) and Admin (Sonata Admin classes) and this is the result:
I noticed that the Entity folder is all in red but it contains only classes with a lot of standard getters and setters. Same thing for the Model folder.
How can I test them without ignoring?
PHPUnit offers some ways to modify how coverage is tracked using annotations on yor tests, such as #covers and #coversNothing. You can also exclude sections of your code from coverage by using #codeCoverageIgnore. How to use them is covered in the docs: https://phpunit.de/manual/current/en/code-coverage-analysis.html
When running the tests you can use command line options to modify some of those settings:
--strict-coverage Be strict about #covers annotation usage.
--disable-coverage-ignore Disable annotations for ignoring code coverage.
If your problem does not stem from limiting coverage on those entities, you should identify which tests use them to see if the methods are actually called. I could imagine that you have mocked them and that is why they are not covered.
Related
I want to separate my tests in unit and integration tests and have an abstract TestCase class for each, e.g. UnitTestCase and IntegrationTestCase.
Is there a nice way to run only those tests that extend UnitTestCase without giving a #group unit annotation to each of these test classes?
The phpunit documentation is very sparse when describing subclassing. Also a google search didn't turn up any useful results.
No. Either use the #group annotation for this or, better IMO, have a tests/unit directory for unit tests as well as a tests/integration directory for integration tests and then define two test suites in phpunit.xml. By default, both will be run. Using --testsuite you can then filter based on the test suite name.
I'm trying to set up a testing suite for my Symfony 3 app, and I'm wondering what the correct method for setting up the test database is. I've found this article, but it doesn't actually explain how to add fixtures programmatically.
Also, it appears their example sets up the test database for every test.
Is there a way to setup a test database which is automatically loaded with fixtures when phpunit is run? The official documentation is kind of sparse
Symfony has different environments you can operate in. By default those are prod(production), dev(developement) and test. Although it may not be exactly what you want, you can configure different config, paramaters, routes and so on for each environment. Read the official documentation for more info but yeah, you can setup your parameters.yml file for test mode which could have a different database configured there.
https://symfony.com/doc/current/configuration/environments.html
If you extend your TestCases from KernelTestCase or WebTestCase, basically extend from \PHPUnit_Framework_TestCase you have methods like setUpBeforeClass() or setUp() which are run by PhpUnit before your test/test cases is/are executed.
Use this to e.g. create your fixtures, load your SQL file or whatever and however you might require your prerequisites for your tests.
This question: Run PHPUnit Tests in Certain Order has an accepted answer which I agree with, but the design problem is with PHP and PHPUnit.
The project I'm testing uses ZF2 and Doctrine. The AbstractHttpControllerTestCase has a method "dispatch" which instantiates a ZF2 Application and goes through all the steps of creating the Response object. These tests are annotated with #covers to ensure other methods aren't covered by running requests during a test. The requests may involve view scripts which invoke view helpers which use all sorts of services, so it becomes infeasible to mock all services used during a given request (and this code would become tedious to copy and maintain for each test).
PHPUnit has the ability to run tests in a separate process, it does this by forking a new PHP instance and feeding it compiled code templates (weird stuff). It will then include all files listed by get_included_files(), which includes everything that ever hit the autoloader. Even with preserveGlobalState disabled, it will still include everything that's been touched by all prior tests in the new process.
Some of the dependencies (installed through composer) use static methods, classes marked final or both. Static methods can be mocked by PHPUnit, final classes have to be overloaded using Mockery as PHPUnit will flat out refuse to create mock objects of final classes. Overloading classes and functions (using the namespace trick) must be done in separate processes as to not influence subsequent tests. So far, so good.
Enter a test which overloads a dependency to set expectations on static methods (on a class which may or may not be marked final), or to set expectations on objects which are not yet instantiated. This will only work if none of the prior tests have ever touched the class to overload and set expectations on, or it'll fail with a "cannot redeclare class" error. PHPUnit has tried to be helpful and included everything to recreate the test environment in the subprocess, but as a result ruins the test case.
Therefore, it would be incredibly useful to mark tests with e.g. "#group isolated" and have those tests run before any other tests without having to invoke PHPUnit twice (besides the inconvenience of it, it would ruin coverage analysis).
Alternatively, if there's a way to override a class that already exists in PHP 5.5, that would allow the stricken test case to fix its precondition. But that's probably not going to happen (runkit is not an acceptable answer in any case).
My Yii app getting phpunit coverage in controllers, models, components, modules but not any views. The problem is that code coverage loader in phpunit includes the view file during preparing a coverage report. Views with forms have calls $this->beginWidget which causes a crash since there is no $this context.
Views dont really have important code or logic but still they have some conditions and even loops to call renderPartial so it would be good to get a view code also covered.
Is there a solution to this problem?
Have you tried extending CWebTestCase? Generally when writing unit tests, you have fixtures and things to provide the necessary data - but with tests on views and 'functional' tests, for web-apps, it's generally easiest to mimic a browser and have it perform actions on the web app as if a user was actually using it. Currently, this mimicking is most easily done with Selenium (in my opinion).
The Yii Guide on Functional Testing is a good place to start as well as the Selenium Documentation. There's also this book that goes over using selenium (I'm not sure if the newest edition does, but I know the previous release with Publication Date: August 11, 2010 did), and Larry Ullman's Yii Book will have chapters on testing and the usage of Selenium in functional tests when he's completed that chapter.
Hope this helps!
Update to further explain CWebTestCase
CWebTestCase extends PHPUnit_Extensions_SeleniumTestCase which directly implements a functional testing foundation that you can use within phpunit in order to test views, test widget creation inside of views, assert that text exists, 'click' on links, etc. These tests are still run from the command line though they require that Selenium-RC server be started upon the test being run and they require a valid browser being configured. A valid browser can be configured with as little code as the following placed inside of the setUp() function:
$this->setBrowser('*firefox /usr/lib/firefox/firefox-bin');
Stating that code coverage cannot be provided by CWebTestCase is not true, as CWebTestCase extends PHPUnit_Extensions_SeleniumTestCase, which provides the following as quoted from the documentation:
PHPUnit_Extensions_SeleniumTestCase can collect code coverage
information for tests run through Selenium:
Copy PHPUnit/Extensions/SeleniumTestCase/phpunit_coverage.php into
your webserver's document root directory. In your webserver's php.ini
configuration file, configure
PHPUnit/Extensions/SeleniumTestCase/prepend.php and
PHPUnit/Extensions/SeleniumTestCase/append.php
as the auto_prepend_file and auto_append_file, respectively. In your test
case class that extends PHPUnit_Extensions_SeleniumTestCase, use
protected $coverageScriptUrl = 'http://host/phpunit_coverage.php';
to configure the URL for the phpunit_coverage.php script.
I am currently going to start from scratch with the phpunit tests for a project. So I was looking into some projects (like Zend) to see how they are doing things and how they organizing their tests.
Most things are pretty clear, only thing I have some problems with is how to organize the test suites properly.
Zend has an AllTests.php from which loads others test suites.
Tough looking at the class it is useing PHPUnit_Framework_TestSuite to create a suite object and then add the other suites to it, but if I look in the PHPUnit docs for organizing tests in PHPUnit versions after 3.4 there is only a description for XML or FileHierarchy. The one using classes to organize the tests was removed.
I haven't found anything that this method is deprecated and projects like Zend are still using it.
But if it is deprecated, how would I be able to organize tests in the same structure with the xml configuration? Executing all tests is no problem, but how would I organize the tests (in the xml) if I only wanted to execute a few tests. Maybe creating several xmls where I only specify a few tests/test suites to be run?
So if I would want to only test module1 and module2 of the application, would I have an extra xml for each and defining test suites only for those modules (classes used by the module) in it. And also one that defines a test suite for all tests?
Or would it be better to use the #group annotation on the specific tests to mark them to be for module1 or module2?
Thanks in advance for pointing me to some best practices.
I'll start of by linking to the manual and then going into what I've seen and heard in the field.
Organizing phpunit test suites
Module / Test folder organization in the file system
My recommended approach is combining the file system with an xml config.
tests/
\ unit/
| - module1
| - module2
- integration/
- functional/
with a phpunit.xml with a simple:
<testsuites>
<testsuite name="My whole project">
<directory>tests</directory>
</testsuite>
</testsuites>
you can split the testsuites if you want to but thats a project to project choice.
Running phpunit will then execute ALL tests and running phpunit tests/unit/module1 will run all tests of module1.
Organization of the "unit" folder
The most common approach here is to mirror your source/ directory structure in your tests/unit/ folder structure.
You have one TestClass per ProductionClass anyways so it's a good approach in my book.
In file organization
One class per file.
It's not going to work anyways if you have more than one test class in one file so avoid that pitfall.
Don't have a test namespace
It just makes writing the test more verbose as you need an additional use statement so I'd say the testClass should go in the same namespace as the production class but that is nothing PHPUnit forces you to do. I've just found it to be easier with no drawbacks.
Executing only a few tests
For example phpunit --filter Factory executes all FactoryTests while phpunit tests/unit/logger/ executes everything logging related.
You can use #group tags for something like issue numbers, stories or something but for "modules" I'd use the folder layout.
Multiple xml files
It can be useful to create multiple xml files if you want to have:
one without code coverage
one just for the unit tests (but not for the functional or integration or long running tests)
other common "filter" cases
PHPBB3 for example does that for their phpunit.xmls
Code coverage for your tests
As it is related to starting a new project with tests:
My suggestion is to use #covers tags like described in my blog (Only for unit tests, always cover all non public functions, always use covers tags.
Don't generate coverage for your integration tests. It gives you a false sense of security.
Always use whitelisting to include all of your production code so the numbers don't lie to you!
Autoloading and bootstrapping your tests
You don't need any sort of auto loading for your tests. PHPUnit will take care of that.
Use the <phpunit bootstrap="file"> attribute to specify your test bootstrap. tests/bootstrap.php is a nice place to put it. There you can set up your applications autoloader and so on (or call your applications bootstrap for that matter).
Summary
Use the xml configuration for pretty much everything
Seperate unit and integration tests
Your unit test folders should mirror your applications folder structure
To only execute specif tests use phpunit --filter or phpunit tests/unit/module1
Use the strict mode from the get go and never turn it off.
Sample projects to look at
Sebastian Bergmanns "Bank Account" example project
phpBB3 Even so they have to fight some with their legacy ;)
Symfony2
Doctrine2
Basic Directory Structure:
I have been experimenting with keeping the test code right next to the code being tested, literally in the same directory with a slightly different file name from the file with the code it is testing. So far I am liking this approach. The idea is you don't have to spend time and energy keeping the directory structure in sync between your code and your test code. So if you change the name of the directory the code is in, you don't then also need to go and find and change the directory name for the test code. This also causes you to spend less time looking for the test code that goes with some code as it is right there next to it. This even makes it less of a hassle to create the file with the test code to begin with because you don't have to first find the directory with the tests, possibly create a new directory to match the one you are creating tests for, and then create the test file. You just create the test file right there.
One huge advantage of this is it means the other employees (not you because you would never do this) will be less likely to avoid writing test code to begin with because it is just too much work. Even as they add methods to existing classes they will be less likely to not feel like adding tests to the existing test code, because of the low friction of finding the test code.
One disadvantage is this makes it harder to release your production code without the tests accompanying it. Although if you use strict naming conventions it still might be possible. For example, I have been using ClassName.php, ClassNameUnitTest.php, and ClassNameIntegrationTest.php. When I want to run all the unit tests, there is a suite that looks for files ending in UnitTest.php. The integration test suite works similarly. If I wanted to, I could use a similar technique to prevent the tests from getting released to production.
Another disadvantage of this approach is when you are just looking for actual code, not test code, it takes a little more effort to differentiate between the two. But I feel this is actually a good thing as it forces us to feel the pain of the reality that test code is code too, it adds its' own maintenance costs, and is just as vitally a part of the code as anything else, not just something off to the side somewhere.
One test class per class:
This is far from experimental for most programmers, but it is for me. I am experimenting with only having one test class per class being tested. In the past I had an entire directory for each class being tested and then I had several classes inside that directory. Each test class setup the class being tested in a certain way, and then had a bunch of methods each one with a different assertion made. But then I started noticing certain conditions I would get these objects into had stuff in common with other conditions it got into from other test classes. The duplication become too much to handle, so I started creating abstractions to remove it. The test code became very difficult to understand and maintain. I realized this, but I couldn't see an alternative that made sense to me. Just having one test class per class seemed like it would not be able to test nearly enough situations without becoming overwhelming to have all that test code inside one test class. Now I have a different perspective on it. Even if I was right, this is a huge dampener on other programmers, and myself, wanting to write and maintain the tests. Now I am experimenting with forcing myself to have one test class per class being tested. If I run into too many things to test in that one test class, I am experimenting with seeing this as an indication that the class being tested is doing too much, and should be broken up into multiple classes. For removing duplication I am trying to stick to simpler abstractions as much as possible that allows everything to exist in one readable test class.
UPDATE
I am still using and liking this approach, but I have found a very good technique for reducing the amount of test code and the amount of duplication. It is important to write reusable assertion methods inside the test class itself that gets heavily used by the test methods in that class. It helps me to come up with the right types of assertion methods if I think of them as internal DSLs (something Uncle Bob promotes, well actually he promotes actually making internal DSLs). Sometimes you can take this DSL concept even further (actually make a DSL) by accepting a string parameter that has a simple value that refers to what kind of test you are trying to perform. For example, one time I made a reusable asssertion method that accepted a $left, $comparesAs, and a $right parameter. This made the tests very short and readable as the code read something like $this->assertCmp('a', '<', 'b').
Honestly, I can't emphasize that point enough, it is the entire foundation of making writing tests something that is sustainable (that you and the other programmers want to keep doing). It makes it possible for the value that tests add to outweigh what they take away. The point is not that you need to use that exact technique, the point is you need to use some kind of reusable abstractions that allow you to write short and readable tests. It might seem like I'm getting off topic from the question, but I'm really not. If you don't do this, you will eventually fall into the trap of needing to create multiple test classes per class being tested, and things really break down from there.