php/pftt2
1
0
Fork 0
mirror of https://github.com/php/pftt2.git synced 2026-03-24 09:12:17 +01:00
Code Issues 46 Packages Projects Releases Wiki Activity

Upgrade bundled PHPUnit #61

New Issue
Closed
opened 2026-01-24 11:40:37 +01:00 by admin · 6 comments
admin commented 2026-01-24 11:40:37 +01:00
Owner
Copy Link

Originally created by @cmb69 on GitHub (Nov 15, 2019).

The files in cache/util/PEAR/pear/PHPUnit are currently PHPUnit 3.6.11, DBUnit 1.2.0 and phpunit-mock-objects; so all pretty old versions, and the latter two projects are even abandoned, whereby the MockObjects have been bundled with PHPUnit in the meantime.

However, the bundled PHPUnit has been patched:

--- b/cache/util/PEAR/pear/PHPUnit/Framework/TestCase.php
+++ a/cache/util/PEAR/pear/PHPUnit/Framework/TestCase.php
@@ -484,6 +484,21 @@
         $this->expectedExceptionCode    = $exceptionCode;
         $this->expectedExceptionTrace   = debug_backtrace();
     }
+	
+	public function pftt_step1() {
+		$this->setUpBeforeClass();
+		$this->setExpectedExceptionFromAnnotation();
+        $this->setUp();
+        $this->checkRequirements();
+        $this->assertPreConditions();
+	}
+	public function pftt_step2() {
+		$this->verifyMockObjects();
+        $this->assertPostConditions();
+	}
+	public function pftt_step3() {
+        $this->tearDown();
+	}
 
     /**
      * @since  Method available since Release 3.4.0
@@ -766,7 +781,6 @@
     public function runBare()
     {
         $this->numAssertions = 0;
-
         // Backup the $GLOBALS array and static attributes.
         if ($this->runTestInSeparateProcess !== TRUE &&
             $this->inIsolation !== TRUE) {
@@ -786,17 +800,15 @@
         }
 
         // Start output buffering.
+        // TODO ob_start();
-        ob_start();
         $this->outputBufferingActive = TRUE;
 
         // Clean up stat cache.
         clearstatcache();
-
         try {
             if ($this->inIsolation) {
                 $this->setUpBeforeClass();
             }
-
             $this->setExpectedExceptionFromAnnotation();
             $this->setUp();
             $this->checkRequirements();
--- b/cache/util/PEAR/pear/PHPUnit/Util/PHP.php
+++ a/cache/util/PEAR/pear/PHPUnit/Util/PHP.php
@@ -115,7 +115,9 @@
                     PHP_BINDIR . '/php',
                     PHP_BINDIR . '/php-cli.exe',
                     PHP_BINDIR . '/php.exe',
+					/* -- begin PFTT -- */
+                    'C:\php-sdk\php-5.4-nts-windows-vc9-x86-r9fe8c58\php.exe',
+					/* -- end PFTT -- */
-                    '@php_bin@',
                 );
                 foreach ($possibleBinaryLocations as $binary) {
                     if (is_readable($binary)) {

Also cache/util/PEAR/phpunit(.bat) have been patched as well.

So we have to figure out the details of upgrading and possibly unbundling:

  • Are these patches necessary? How to do without them?
  • Is DBUnit actually used?
  • Which further adaptions would be needed to upgrade to some supported PHPUnit version?
  • Do we have to stick with a slightly older PHPUnit version, to be able to test the PHP 5.6 and 7.0 backports?
Originally created by @cmb69 on GitHub (Nov 15, 2019). The files in cache/util/PEAR/pear/PHPUnit are currently [PHPUnit 3.6.11](https://github.com/sebastianbergmann/phpunit/releases/tag/3.6.11), [DBUnit 1.2.0](https://github.com/sebastianbergmann/dbunit/releases/tag/1.2.0) and [phpunit-mock-objects](https://github.com/sebastianbergmann/phpunit-mock-objects/releases/tag/1.1.1); so all pretty old versions, and the latter two projects are even [abandoned](https://github.com/sebastianbergmann/dbunit/issues/217), whereby the MockObjects have been [bundled with PHPUnit](https://github.com/sebastianbergmann/phpunit-mock-objects/issues/425) in the meantime. However, the bundled PHPUnit has been patched: ````.diff --- b/cache/util/PEAR/pear/PHPUnit/Framework/TestCase.php +++ a/cache/util/PEAR/pear/PHPUnit/Framework/TestCase.php @@ -484,6 +484,21 @@ $this->expectedExceptionCode = $exceptionCode; $this->expectedExceptionTrace = debug_backtrace(); } + + public function pftt_step1() { + $this->setUpBeforeClass(); + $this->setExpectedExceptionFromAnnotation(); + $this->setUp(); + $this->checkRequirements(); + $this->assertPreConditions(); + } + public function pftt_step2() { + $this->verifyMockObjects(); + $this->assertPostConditions(); + } + public function pftt_step3() { + $this->tearDown(); + } /** * @since Method available since Release 3.4.0 @@ -766,7 +781,6 @@ public function runBare() { $this->numAssertions = 0; - // Backup the $GLOBALS array and static attributes. if ($this->runTestInSeparateProcess !== TRUE && $this->inIsolation !== TRUE) { @@ -786,17 +800,15 @@ } // Start output buffering. + // TODO ob_start(); - ob_start(); $this->outputBufferingActive = TRUE; // Clean up stat cache. clearstatcache(); - try { if ($this->inIsolation) { $this->setUpBeforeClass(); } - $this->setExpectedExceptionFromAnnotation(); $this->setUp(); $this->checkRequirements(); --- b/cache/util/PEAR/pear/PHPUnit/Util/PHP.php +++ a/cache/util/PEAR/pear/PHPUnit/Util/PHP.php @@ -115,7 +115,9 @@ PHP_BINDIR . '/php', PHP_BINDIR . '/php-cli.exe', PHP_BINDIR . '/php.exe', + /* -- begin PFTT -- */ + 'C:\php-sdk\php-5.4-nts-windows-vc9-x86-r9fe8c58\php.exe', + /* -- end PFTT -- */ - '@php_bin@', ); foreach ($possibleBinaryLocations as $binary) { if (is_readable($binary)) { ```` Also cache/util/PEAR/phpunit(.bat) have been patched as well. So we have to figure out the details of upgrading and possibly unbundling: * Are these patches necessary? How to do without them? * Is DBUnit actually used? * Which further adaptions would be needed to upgrade to some supported PHPUnit version? * Do we have to stick with a slightly older PHPUnit version, to be able to test the PHP 5.6 and 7.0 backports?
admin closed this issue 2026-01-24 11:40:37 +01:00
admin commented 2026-01-24 11:40:38 +01:00
Author
Owner
Copy Link

@lavturo commented on GitHub (Nov 20, 2019):

To answer a few of these questions:

For the patches, it is hard to say if they are needed as of now since app testing is currently not working. We could keep these as reference if we were to update PHPUnit.

DBUnit is only a part of the PEAR directory. It is part of some .php files. Otherwise, it is not referenced in pftt itself. However, the PEAR directory is referenced once. This one reference is for PFTT to find the autoload.php for PHPUnit (located at pftt2/cache/util/PEAR/pear/PHPUnit). Otherwise, it will give an error about not being able to find said file.

I believe, we would only have to update the test.php file that is generated by PFTT, if we wanted to move or update PHPUnit. However, I am unsure of how test.php used PHPUnit. So I would have to look through that file before commenting on what else needs to be updated or adapted.

If we want to be able to do app testing for PHP 5.6 and 7.0, then we would only be able to upgrade to PHPUnit 5.

@lavturo commented on GitHub (Nov 20, 2019): To answer a few of these questions: For the patches, it is hard to say if they are needed as of now since app testing is currently not working. We could keep these as reference if we were to update PHPUnit. DBUnit is only a part of the PEAR directory. It is part of some .php files. Otherwise, it is not referenced in pftt itself. However, the PEAR directory is referenced [once](https://github.com/php/pftt2/blob/94eb81a9e90be9f8ad1f576d9bf043e7952cc81a/src/com/mostc/pftt/model/app/PhpUnitDist.java#L88). This one reference is for PFTT to find the `autoload.php` for PHPUnit (located at pftt2/cache/util/PEAR/pear/PHPUnit). Otherwise, it will give an error about not being able to find said file. I believe, we would only have to update the `test.php` file that is generated by PFTT, if we wanted to move or update PHPUnit. However, I am unsure of how `test.php` used PHPUnit. So I would have to look through that file before commenting on what else needs to be updated or adapted. If we want to be able to do app testing for PHP 5.6 and 7.0, then we would only be able to upgrade to [PHPUnit 5](https://phpunit.de/supported-versions.html).
admin commented 2026-01-24 11:40:38 +01:00
Author
Owner
Copy Link

@cmb69 commented on GitHub (Dec 4, 2019):

@lavturo, it's actually that test.php that worries me most. It seems that this is a variant of an instantiated TestCaseMethod.tpl.dist, and as such may be highly dependent on the PHPUnit version (i.e. would likely have to be adapted for every upgrade). It might be worthwhile to have a look at the officially supported customizations (see respective PHPUnit 5 docs); perhaps these already offer what we need?

@cmb69 commented on GitHub (Dec 4, 2019): @lavturo, it's actually that test.php that worries me most. It seems that this is a variant of an instantiated [TestCaseMethod.tpl.dist](https://github.com/php/pftt2/blob/master/cache/util/PEAR/pear/PHPUnit/Framework/Process/TestCaseMethod.tpl.dist), and as such may be highly dependent on the PHPUnit version (i.e. would likely have to be adapted for every upgrade). It might be worthwhile to have a look at the officially supported customizations (see respective [PHPUnit 5 docs](https://phpunit.de/manual/5.7/en/extending-phpunit.html#extending-phpunit.PHPUnit_Framework_TestListener)); perhaps these already offer what we need?
admin commented 2026-01-24 11:40:38 +01:00
Author
Owner
Copy Link

@lavturo commented on GitHub (Dec 5, 2019):

From what I have found, test.php is generated from PhpUnitTemplate.goovy. The first part of it seems similar to the file you linked.

Any change to that file gives the same error: "Class 'WP_UnitTestCase' not found". This error occurs due to the bootstrap file. This makes me wonder if the current wordpress-tests I am using has its own problems or if it is something else all together.

The officially supported customizations seem to be helpful. We wouldn't need to change any of the actual tests themselves though, do we?

@lavturo commented on GitHub (Dec 5, 2019): From what I have found, `test.php` is generated from [PhpUnitTemplate.goovy](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/src/com/mostc/pftt/model/app/PhpUnitTemplate.groovy#L74). The first part of it [seems similar](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/src/com/mostc/pftt/model/app/PhpUnitTemplate.groovy#L294) to the file you linked. Any change to that file gives the same error: "Class 'WP_UnitTestCase' not found". This error occurs due to the [bootstrap file](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/src/com/mostc/pftt/model/app/PhpUnitTemplate.groovy#L224). This makes me wonder if the current wordpress-tests I am using has its own problems or if it is something else all together. The officially supported customizations seem to be helpful. We wouldn't need to change any of the actual tests themselves though, do we?
admin commented 2026-01-24 11:40:38 +01:00
Author
Owner
Copy Link

@cmb69 commented on GitHub (Dec 5, 2019):

I ran the wordpress-tests a few weeks ago standalone (i.e. without PFTT), and besides some test failures, that worked fine. I guess that PFTT only was run with some old version of these tests (most likely even before they have been merged into wordpress-develop). Also, the hard-coded paths in PHPUnitTemplate.groovy look fishy; there's certainly no need to include symfony for running WP tests. Possibly, these have been adjusted manually for each app test scenario, and only this "snapshot" has been committed? (see also a few lines below; there are several include paths for different app scenarios; WordPress doesn't seem to be one of them, though)

The PHPUnit customizations should indeed only affect the test runner, so no modifications to the actual tests should be necessary (and we certainly want to avoid anyway).

@cmb69 commented on GitHub (Dec 5, 2019): I ran the wordpress-tests a few weeks ago standalone (i.e. without PFTT), and besides some test failures, that worked fine. I guess that PFTT only was run with some old version of these tests (most likely even before they have been merged into [wordpress-develop](https://github.com/WordPress/wordpress-develop)). Also, the [hard-coded paths in PHPUnitTemplate.groovy](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/src/com/mostc/pftt/model/app/PhpUnitTemplate.groovy#L44-L72) look fishy; there's certainly no need to include symfony for running WP tests. Possibly, these have been adjusted manually for each app test scenario, and only this "snapshot" has been committed? (see also a few lines below; there are several include paths for different app scenarios; WordPress doesn't seem to be one of them, though) The PHPUnit customizations should indeed only affect the test runner, so no modifications to the actual tests should be necessary (and we certainly want to avoid anyway).
admin commented 2026-01-24 11:40:38 +01:00
Author
Owner
Copy Link

@lavturo commented on GitHub (Dec 5, 2019):

There is a call made in AbstractPhpUnitTestCaseRunner.java that gets the info that is stored in wordpress.groovy.

As for the include path, it is updated and passed from PhpUnitDist.java. It grabs every directory in the specified source test pack directory (which is defined from wordpress.groovy).

I believe the hard-coded paths were left there so that they know what directories are needed if they were to try and run a test for one of those specific app scenarios. However, they might be outdated if the test source packs for those app scenarios have been updated with different directories.

@lavturo commented on GitHub (Dec 5, 2019): There is a call made in [AbstractPhpUnitTestCaseRunner.java](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/src/com/mostc/pftt/runner/AbstractPhpUnitTestCaseRunner.java#L102-L120) that gets the info that is stored in [wordpress.groovy](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/conf/app/wordpress.groovy#L18). As for the include path, it is updated and passed from [PhpUnitDist.java](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/src/com/mostc/pftt/model/app/PhpUnitDist.java#L90). It grabs every directory in the specified source test pack directory (which is defined from [wordpress.groovy](https://github.com/php/pftt2/blob/c00d4846bcc545ae7ad22f0d9433f9077d1c6705/conf/app/wordpress.groovy#L29)). I believe the hard-coded paths were left there so that they know what directories are needed if they were to try and run a test for one of those specific app scenarios. However, they might be outdated if the test source packs for those app scenarios have been updated with different directories.
admin commented 2026-01-24 11:40:39 +01:00
Author
Owner
Copy Link

@cmb69 commented on GitHub (Jan 17, 2020):

Since bf0a98eaae updated to PHPUnit 5, this ticket can be closed.

@cmb69 commented on GitHub (Jan 17, 2020): Since bf0a98eaae97ce948eb32b922832599ddba960a8 updated to PHPUnit 5, this ticket can be closed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
enhancement
invalid
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: php/pftt2#61
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?