assertFileEquals()

assertFileEquals() assertFileEquals(string $expected, string $actual[, string $message = '']) Reports an error identified by $message if the file specified by $expected does not have the same contents as the file specified by $actual. assertFileNotEquals() is the inverse of this assertion and takes the same arguments. Example A.22: Usage of assertFileEquals() <?php use PHPUnit\Framework\TestCase; class FileEqualsTest extends TestCase { public function testFailure() { $this

assertIsReadable()

assertIsReadable() assertIsReadable(string $filename[, string $message = '']) Reports an error identified by $message if the file or directory specified by $filename is not readable. assertNotIsReadable() is the inverse of this assertion and takes the same arguments. Example A.31: Usage of assertIsReadable() <?php use PHPUnit\Framework\TestCase; class IsReadableTest extends TestCase { public function testFailure() { $this->assertIsReadable('/path/to/unreadable'); }

@codeCoverageIgnore*

@codeCoverageIgnore* The @codeCoverageIgnore, @codeCoverageIgnoreStart and @codeCoverageIgnoreEnd annotations can be used to exclude lines of code from the coverage analysis. For usage see the section called “Ignoring Code Blocks”.

Database Testing

Many beginner and intermediate unit testing examples in any programming language suggest that it is perfectly easy to test your application's logic with simple tests. For database-centric applications this is far away from the reality. Start using Wordpress, TYPO3 or Symfony with Doctrine or Propel, for example, and you will easily experience considerable problems with PHPUnit: just because the database is so tightly coupled to these libraries. Make sure you have the PHP extension pdo and da

@large

@large The @large annotation is an alias for @group large. If the PHP_Invoker package is installed and strict mode is enabled, a large test will fail if it takes longer than 60 seconds to execute. This timeout is configurable via the timeoutForLargeTests attribute in the XML configuration file.

@after

@after The @after annotation can be used to specify methods that should be called after each test method in a test case class. use PHPUnit\Framework\TestCase; class MyTest extends TestCase { /** * @after */ public function tearDownSomeFixtures() { // ... } /** * @after */ public function tearDownSomeOtherFixtures() { // ... } }

Logging

PHPUnit can produce several types of logfiles. Test Results (XML) The XML logfile for test results produced by PHPUnit is based upon the one used by the JUnit task for Apache Ant. The following example shows the XML logfile generated for the tests in ArrayTest: <?xml version="1.0" encoding="UTF-8"?> <testsuites> <testsuite name="ArrayTest" file="/home/sb/ArrayTest.php" tests="2" assertions="2" failures="0" er

assertThat()

assertThat() More complex assertions can be formulated using the PHPUnit_Framework_Constraint classes. They can be evaluated using the assertThat() method. Example A.49 shows how the logicalNot() and equalTo() constraints can be used to express the same assertion as assertNotEquals(). assertThat(mixed $value, PHPUnit_Framework_Constraint $constraint[, $message = '']) Reports an error identified by $message if the $value does not match the $constraint. Example A.49: Usage of assertThat() <

Incomplete and Skipped Tests

Incomplete Tests When you are working on a new test case class, you might want to begin by writing empty test methods such as: public function testSomething() { } to keep track of the tests that you have to write. The problem with empty test methods is that they are interpreted as a success by the PHPUnit framework. This misinterpretation leads to the test reports being useless -- you cannot see whether a test is actually successful or just not yet implemented. Calling $this->fail() in th

Testing Practices

You can always write more tests. However, you will quickly find that only a fraction of the tests you can imagine are actually useful. What you want is to write tests that fail even though you think they should work, or tests that succeed even though you think they should fail. Another way to think of it is in cost/benefit terms. You want to write tests that will pay you back with information. --Erich Gamma During Development When you need to make a change to the internal structure