Tests at core version 9.1 have just started to fail with
Behat\Mink\Exception\ExpectationException:
Current page is "/admin/config/workflow/rules/reactions/edit/test_condition_rules_data_comparison?uuid=18a51c33-6f4d-4c51-a714-73a7f870cc82" but "/admin/config/workflow/rules/reactions/edit/test_condition_rules_data_comparison" expected.
The failing tests are ConditionsFormTest.php line 115 and ActionsFormTest.php line 115.
Tests at 8.8, 8.9 and 9.0 still pass cleanly.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | travis.jpeg | 320.53 KB | jonathan1055 |
| #4 | 3168040-4.query-string-in-address.patch | 4.01 KB | jonathan1055 |
Comments
Comment #2
jonathan1055 commentedOK I can work on this, provided you have not started on it?
Comment #3
tr commentedNope, I'm not working on it.
Comment #4
jonathan1055 commentedIt turns out that the solution was quite simple in the end. Using
addressEquals()in core versions up to and including 9.0 just checked the actual main address part, ignoring any query string in the url. This was actually quite helpful. Anyway, in 9.1 the full url is checked, including the query string. We can create the full string because we have the->getUuid()method in the $action and $condition. But we cannot useaddressEquals()because in core version prior to 9.1 the?uuid=...is not in the value being checked.Therefore I changed the assertions to use
addressMatches()which takes a regex, and specified a pattern which allows for the string "?uuid=.." or blank.I needed to add a 9.1 branch to the Travis test file, to check that my changes worked. I've added a nice way to specify and display the allowed deprecations per branch (screen shot attached), because there are deprecations at 9.1. It is clean up to and including 9.0.
Comment #5
tr commentedYeah, I thought it would be easy. This is just the start of dealing with non-BC changes in D9.1 though ... more to come I'm sure ...
We can work on deprecations as we encounter them - just post an issue with #3089502: [meta] Rules deprecated code as the parent. Priority will be to deal with things that break tests, like this.
I also opened the same issue for Flag, if you're feeling ambitious - #3168046: D9.1 test fails because of core change
Comment #7
tr commentedCommitted.
Comment #8
jonathan1055 commentedOK I may look at #3168046: D9.1 test fails because of core change but I also have plenty of work with Scheduler, Coder and Devel, not to mention all the great stuff here in Rules that we really need to resolve to get an alpha7 release. Currently, other contrib modules that want to use/test Rules in D9 have to use the latest dev in a test suite, which is not desirable as it is a moving target.
I will look at all those Rules issues you listed, work out what the blockages and inter-dependencies are, and try to work out what we need to do, in what order.
[edit: That's nice. My link to the Scheduler issue queue automatically filled in the number of issues]