Problem/Motivation
\Drupal\Tests\layout_builder\Unit\SectionTest::testUnsetThirdPartySetting()
declares its use of a data provider, providerTestUnsetThirdPartySetting
; however, the test method does not accept any arguments. Therefore, the providerTestUnsetThirdPartySetting()
provider method doesn't do anything.
In the case of non-existent providers and non-existent keys, the current test code performs unsets but fails to follow those actions with assertions.
For consistency with the other tests in the class, data should be provided by a data provider.
Proposed resolution
Modify SectionTest::testUnsetThirdPartySetting()
to use a data provider.
Modify SectionTest::testUnsetThirdPartySetting()
to test for non-existent providers and non-existent keys.
Remaining tasks
Submit patchReview
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
None.
Comment | File | Size | Author |
---|---|---|---|
#15 | interdiff-11-15.txt | 499 bytes | Hardik_Patel_12 |
#15 | 3161300-15.patch | 2.09 KB | Hardik_Patel_12 |
#11 | 3161300-11.patch | 2.04 KB | TR |
Comments
Comment #2
Chris Burge CreditAttribution: Chris Burge at University of Nebraska commentedPatch attached. Passing tests will confirm the removed code is unused.
Comment #3
jungle@Chris Burge, thanks for filing this.
I guess the original intention is to use the data provider, but somehow forgot or did not notice that it does not work at all.
So Instead of removing the
data provider
, let's add the arguments totestUnsetThirdPartySetting()
and rewritetestUnsetThirdPartySetting()
to make it work.Comment #4
jungleTagging "Bug Smash Initiative"
Comment #5
Kristen PolThanks for the patch.
1) I looked for similar test code and see the following which follows a similar pattern.
2)
unsetThirdPartySetting
takes arguments$provider
and$key
so that looks correct:public function unsetThirdPartySetting($provider, $key) {
.3) The goal is to make sure that the following data is provided in
providerTestUnsetThirdPartySetting
which is appears to do.The mapping is as such:
is covered by:
and
is covered by:
and
is covered by:
and
is covered by:
4) If tests pass, then this appears RTBC to me.
Comment #6
Kristen PolAh, this should be on 9.1.x. Kicking off tests for 9.1.x.
Comment #7
Chris Burge CreditAttribution: Chris Burge at University of Nebraska commented#3 is unnecessary. The test doesn’t need a data provider. It’s using third-party settings set in
::setUp()
. Adding a data provider doesn’t change the validity of the existing test coverage.My vote is to proceed with #2 because it 1) preserves valid test coverage and 2) doesn’t require unnecessary code.
Comment #8
longwaveI disagree with #2 because the last two lines of the test method make changes but then don't assert anything. I think the data provider adds some value here, reducing repetition and making this more like the other test methods in the class. Therefore I think #3 is the better option.
Comment #9
TR CreditAttribution: TR commentedI agree with this (#3).
And while we never NEED a dataProvider, it is a great way to document what is being tested. By separating the test data from the test methods it makes it easy to see problems with what we're testing, it helps to ensure consistency between test cases, and it makes it simple to extend the test should edge-case failures arise in the future. Plus with a provider failure of one data set won't prevent the other data sets from running ...
Also,
That't true, and when put into a dataProvider these cases are now checked with assertions, and one of the cases was found to be incomplete so the data set had to be changed so the assertion would work. That proves the usefulness of the dataProvider - it detected something that we thought was being tested by really wasn't being tested. Now it is...
Besides, all the code is basically there already, this is just a minor modification of what's there, it just makes it better.
The only improvement I would suggest is to add dataset descriptions via array keys, that way instead of seeing something like "data set 2 failed" PHPUnit will show us the key of the dataset - choosing a descriptive string as the key also documents what each dataset is intended to test.
Comment #10
tim.plunkettThis was added in #2942661: Sections should have third-party settings, whoops.
Let's proceed with #3.
I agree with @TR about adding keys to the $data[] declarations (idk why we didn't do that in the first place).
Comment #11
TR CreditAttribution: TR commentedWith the keys, and an interdiff.
Comment #12
longwaveEven better now.
Comment #13
Chris Burge CreditAttribution: Chris Burge at University of Nebraska commentedY'all had a busy weekend. First, this all looks fine. Second, let's update the issue title/summary to reflect the change of scope and direction.
When I was reviewing #3 on my phone, I missed that there were two missing assertions.
Per #8 and #10, I'm refiling this as a bug. The code did not operate as intended.
Re #9, I'm going to keep those rationale for using a data provider handy. In the past, I've been admonished to remove them because of the performance cost (not a core issue - can't find it at the moment).
+1 for committing
Comment #14
Chris Burge CreditAttribution: Chris Burge at University of Nebraska commentedLooks like a typo slipped past us:
Comment #15
Hardik_Patel_12 CreditAttribution: Hardik_Patel_12 at QED42 for Drupal India Association commentedCorrecting typo for testUnsetThirdPartySetting()
Comment #16
longwaveComment #19
larowlanCommitted 84bae9d and pushed to 9.1.x. Thanks!
c/p to 9.0.x and 8.9.x as this is a bug fix and non-disruptive. Having the branches in sync will mean other backports are likely to apply cleanly.