Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The parent issue highlights test that can be convert to phpunit related tests.
The tests under the spotlight here:
./Image/ToolkitSetupFormTest.php
./Image/ToolkitTest.php
./Image/ToolkitTestBase.php
We are cutting off legacy support for the implicit public API that is ToolkitTestBase.php
Here is the change record.
Comment | File | Size | Author |
---|---|---|---|
#41 | interdiff-2862641-38-41.txt | 456 bytes | martin107 |
#41 | unconfirmed-2862641-41.patch | 8.64 KB | martin107 |
#29 | interdiff-2862641-26-29.txt | 596 bytes | martin107 |
#23 | btb-2862641-23.patch | 5.66 KB | martin107 |
#16 | next-2862641-16.patch | 5.01 KB | martin107 |
Comments
Comment #2
martin107 CreditAttribution: martin107 as a volunteer commentedInitial iteration - Just moving files and taking care of namespaces.
Comment #3
martin107 CreditAttribution: martin107 as a volunteer commentedComment #5
jofitz CreditAttribution: jofitz at ComputerMinds commentedApparently ToolkitTestBase.php is also referenced in a couple of other files too.
Comment #6
martin107 CreditAttribution: martin107 as a volunteer commentedpatch looks good --- what does not is my title :(
Comment #8
martin107 CreditAttribution: martin107 as a volunteer commented1) WebTests was the old source of drupalGetTestFiles, now ToolkitTestBase is that common point from which to pick up the method.
2) Converted deprecated SafeMarkup into FormattableMarkup
@Jo Fitzgerald if you want to work on this just unassign me... and I will help out with reviews. and also start on another conversion issue.
Comment #10
martin107 CreditAttribution: martin107 as a volunteer commented@Jo Fitzgerald can I pick your brains .....
My first patch timed out, I assume, because the time spend looking for the missing base class exploded and tripped a fail-safe
How did you know to correct the problems .... was it from inspection of the error logs or from knowledge of the sub-module
I ask because when I mirror my actions in #2862885: Batch: Convert system functional tests to phpunit
I trip the fail-safe
Comment #11
jofitz CreditAttribution: jofitz at ComputerMinds commentedTo get to the bottom of the initial problems I click to see more details of the test failure (https://www.drupal.org/pift-ci-job/627973), then clicked "View results on dispatcher" (https://dispatcher.drupalci.org/job/drupal_patches/7129/) and "Console Output" (https://dispatcher.drupalci.org/job/drupal_patches/7129/console). Scrolling to the bottom I found the error:
Hope that helps.
Comment #12
dawehnerNote: We need to keep the existing base class around.
Any reason you extend from JavascriptTestBase and not BrowserTestBase ?
Comment #13
martin107 CreditAttribution: martin107 as a volunteer commentedMay I ask what you are thinking when you say
Is that so it will present the minimum disruption to contrib modules?
As I understand no new simpletest test will be accepted into core and there is an inevitable slow drift moving thing for example from
Drupal\system\Tests\Image
into the
Drupal\Tests\system\XYZ
namespace.
If contrib is not a factor - am I free so intercept what you say as
"we need to find a place within the Drupal\Tests\system\ namespace so that it can also be used in unit tests?"
Comment #14
martin107 CreditAttribution: martin107 as a volunteer commented@Jo Fitzgerald thanks for the prompt reply....
@dawehner
No reason that withstands a closer look ... thank you.
Comment #15
dawehnerPlease don't change that as part of the conversion. This makes the patch harder to review for both the committer and the other reviewers.
Comment #16
martin107 CreditAttribution: martin107 as a volunteer commentedFair enough..removed
Removed a few deprecated calls of the form
Comment #18
boaloysius CreditAttribution: boaloysius as a volunteer commentedmade changes as per #15. Haven't touched deprecated calls as in #16.
Comment #19
boaloysius CreditAttribution: boaloysius as a volunteer commentedComment #21
dawehnerNote: Given that
\Drupal\Core\ImageToolkit\ImageToolkitBase
is in core, I think the tests should be moved tocore/tests/Drupal/FunctionalTests
Comment #22
boaloysius CreditAttribution: boaloysius as a volunteer and at Google Summer of Code commentedComment #23
martin107 CreditAttribution: martin107 as a volunteer commented1) That is a good idea - Moved Image directory.
2) Converted a few deprecated calls to SafeMarkup::format()
I have an issue which I cannot solve ... I would be grateful if someone could get me over the hump
the test module image_test still resides as /modules/system/tests/modules/image_test
now that image is no longer in system we need to find a good home for it.
It tried a few directories within the new directory structure but the autoloader failed to pick it up... advice welcome
Comment #25
dawehnerThese changes are out of scope, aka. they increase the patch size more than needed. Do you mind reverting those changes?
Comment #26
martin107 CreditAttribution: martin107 as a volunteer commentedSorry, I have the memory of a goldfish
this is not the first time in this issue I replaced the deprecated method calls.... martin107--
The real source of the errors is that in backing out the changes last time I did not restore the "use Smarkmarkup" at the start of the file.
Comment #28
dawehnerHey, no worries.
Comment #29
martin107 CreditAttribution: martin107 as a volunteer commentedThanks, it is hard to judge emotions in the issue queue -- thanks for the suicide watch but - in reality I am generally a happy bunny :)
This change is a one line change to make the last test pass.
Comment #30
dawehnerNice minimal changes, I think this is ready to go.
Comment #31
michielnugter CreditAttribution: michielnugter as a volunteer and at Synetic commentedComment #32
alexpottWe need to leave base classes in place and deprecate them as this might be extended by contrib.
Comment #33
martin107 CreditAttribution: martin107 as a volunteer commentedthat is a good push back
Comment #34
martin107 CreditAttribution: martin107 as a volunteer commentedSorry testbot this is what I wanted ...
Comment #36
dawehnerIs there a reason these methods are marked as public?
You want to use
assertEmpty()
here and just skip the second assertionComment #37
martin107 CreditAttribution: martin107 as a volunteer commentedThere is a DrupalCon on at the moment .... so I am just signalling ... I am working on this now.
Comment #38
martin107 CreditAttribution: martin107 as a volunteer commentedGiven a recent talks about the hazards of implied API's
https://events.drupal.org/baltimore2017/sessions/backwards-compatibility...
public methods on base class are "API" --- That is a really good idea.
If I understood the talk correctly -- at one point there seems to be widespread support of a yet unconfirmed policy of
going through the list of undeclared internal APIs in this document and marking them as such.
https://www.drupal.org/node/2550249
With that in mind "test" is on the list so I am adding a @internal tag to the converted version of ToolkitTestBase.
I try to see both sides of any argument --- Image manipulation is something that contrib might want to do alot
so declaring this new API as subject to change ... might be a problem.
#36.2
I would like to constructively disagree ....
I see this code as defensively written with good DX in mind.... when things blow up
the pairs of two seemingly duplicated asserts as subtly different and can be read as
It pains me to say good DX ... to criticise the programming style of the second example
this is unreadable code -- it is crying out to be broken into meaningful partial booleans
$expecting_apply = in_array('apply', $expected);
$count_mismatch = count(array_intersect($unexpected, $operations)) !== count($unexpected);
so that the can say the mismatch is only a problem if apply was expected
if ( $countMismatch && !expected_apply )
or something like that....
but this issue is supposed to be a conversion exercise ... If you would like me open a new issue ... that is something I would work on!
Sorry if this is a awful lots of words for such a small patch.
Comment #39
martin107 CreditAttribution: martin107 as a volunteer commentedIssue summary changes
We are cutting off legacy support for the implicit public API that is ToolkitTestBase.php
Here is the change record.
Comment #40
dawehnerWhile I totally agree this is an important discussion to have, can we please leave them out of these conversions? Any of those changes requires every other person involved to think about it.
Do you want to open up an issue to discuss best practices for test base classes (like adding @internal when it should be just used for the module itself). There are test base classes, which should be used by other implementors/entity types etc.
Thank you :)
Comment #41
martin107 CreditAttribution: martin107 as a volunteer commentedThere is already an issue which expresses many of the things I want to say ...
#2873395: [meta] Add @internal to core classes, methods, properties
Ok, as for the patch I have dropped the @internal tag.
Comment #42
dawehnerThank you @martin107!
Comment #45
catchCommitted/pushed to 8.4.x and cherry-picked to 8.3.x, thanks!
Fixed this on commit.
Comment #47
quietone CreditAttribution: quietone at PreviousNext commentedPublished the change record.