Opened 9 years ago
Closed 9 years ago
#34240 closed defect (bug) (invalid)
Backward compatibility broken for unit test lib
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.4 |
Component: | Build/Test Tools | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
It's no more possible to use the unit test lib with any wp version older than the trunk one.
Here is the error I have while I try to run my tests
Class 'WP_REST_Server' not found in /private/tmp/wordpress-tests-lib/includes/spy-rest-server.php on line 3
The issue is related to this commit: [34928]
A patch is attached to solve the issue.
Attachments (1)
Change History (7)
#2
follow-up:
↓ 3
@
9 years ago
Hi marcello.colacino, welcome to Trac!
A similar issue was previously discussed in #33888.
Why are you using the tests of trunk and not the tests from the specific branches?
#3
in reply to:
↑ 2
@
9 years ago
Replying to SergeyBiryukov:
Hi marcello.colacino, welcome to Trac!
A similar issue was previously discussed in #33888.
Why are you using the tests of trunk and not the tests from the specific branches?
HI SergeyBiryukov, first of all thanks for the feedback
I'm using the trunk version in order to be able to exploit in my test suite all new features available
I also thought indeed it was designed to mantain a backward compatibility ...
Look for instance here: http://develop.svn.wordpress.org/trunk/tests/phpunit/includes/mock-image-editor.php
I understand that using specific-branches phpunit lib solve the current issues,
Could you tell me which is the best workflow to be used for testing different WP version?
For instnace: I'm using WP_Ajax_UnitTestCase in my tests, introduced in WP 3.4.0
How I should manage it if I would validate my code on a previous version?
#4
@
9 years ago
This change also broke all my unit tests for my plugin on Travis CI:
https://travis-ci.org/slimndap/wp-theatre/builds/84665137
#5
@
9 years ago
@slimndap I've submitted a pull request to fix your tests.
Generally, the solution is to update your setup script to use the tagged version of WP tests that correlates with your WordPress version.
Patch to fix issue on revision 34928