Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[DomCrawler][FrameworkBundle] Add assertAnySelectorText* #50306

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Aug 4, 2023
Merged

[DomCrawler][FrameworkBundle] Add assertAnySelectorText* #50306

merged 1 commit into from
Aug 4, 2023

Conversation

SVillette
Copy link
Contributor

@SVillette SVillette commented May 12, 2023 •
edited
Loading

Q A
Branch? 6.4
Bug fix? no
New feature? yes
Deprecations? no
Tickets Fix #48213
License MIT
Doc PR -

As mentioned in #48213, it can be useful to check that any selector contains/equals a string. But the current assertSelectorTextSame and assertSelectorTextContains only assert with the first selector.

Before this PR, the solution was

<ul>
    <li>test1</li>
    <li>test2</li>
    <li>test3</li>
</ul>
public function testIndexAction(): void
{
    $client = self::createClient();
    $crawler = $client->request('GET', '/');

    $nodes = $crawler->filter('ul li')->each(fn(Crawler $node) => $node->text());
    self::assertContains('test3', $nodes);
}

And after this changes

public function testIndexAction(): void
{
    $client = self::createClient();
    $crawler = $client->request('GET', '/');

    self::assertAnySelectorTextSame('ul li', 'test3');
    self::assertAnySelectorTextContains('ul li', 'tes');
    self::assertAnySelectorTextNotContains('ul li', 'foo');
}

A doc PR will be made if the changes are accepted

@carsonbot carsonbot added this to the 6.3 milestone May 12, 2023
@SVillette SVillette force-pushed the dom_crawler_assert_any_selector branch from 43c800e to 511dcd7 Compare May 12, 2023 19:29
@SVillette
Copy link
Contributor Author

SVillette commented May 12, 2023 •
edited
Loading

The failing tests seems unrelated to this PR (related to the Notifier component).
However, Psalm fails with the 2 same errors:

  • The first one is because phpunit defines method \PHPUnit\Framework\Constraint\Constraint::matches($other) and the signature of the first argument is changed (renamed to $crawler). Should I fix this error as all other constraints have the same naming ?
  • The second error happens because of the type of $crawler argument. As the previous error, all other constraints have the same signature on matches() method.

What is the correct fix here ? Should this errors be added to the Psalm baseline ?
Thanks

@stof
Copy link
Member

stof commented May 15, 2023

Instead of @param Crawler, the argument should have the same type than in the parent class, with a first check inside the class about unsupported type for the asserted value.

@SVillette
Copy link
Contributor Author

Instead of @param Crawler, the argument should have the same type than in the parent class, with a first check inside the class about unsupported type for the asserted value.

Sure, I get what you meant here.
My question was about consistency with the other Constraint classes. For example, the class CrawlerSelectorCount has been added "recently" (5 months ago) and all methods of this class have the same signature than the methods of the constraints I added in this PR. I think other constraints throw Psalm errors too but this errors have been added to the baseline.

@stof
Copy link
Member

stof commented May 15, 2023

Our CI generates a baseline automatically for each run, so that it complains only about new issues.

@SVillette
Copy link
Contributor Author

Ok, so I guess you want it to be fixed for this PR and another PR can fix it for the other constraints ?

@stof
Copy link
Member

stof commented May 15, 2023

indeed

@SVillette
Copy link
Contributor Author

@stof Psalm errors are fixed now, let me now if you want me to make other changes.

stof
stof reviewed May 23, 2023
View reviewed changes
@nicolas-grekas nicolas-grekas modified the milestones: 6.3, 6.4 May 23, 2023
@SVillette SVillette force-pushed the dom_crawler_assert_any_selector branch from 17dcdb0 to 94eca69 Compare June 1, 2023 09:28
@SVillette SVillette force-pushed the dom_crawler_assert_any_selector branch from 837192c to 35c7b33 Compare July 12, 2023 13:06
@fabpot fabpot force-pushed the dom_crawler_assert_any_selector branch from 35c7b33 to 98ebda2 Compare August 4, 2023 09:39
@fabpot
Copy link
Member

fabpot commented Aug 4, 2023

Thank you @SVillette.

@fabpot fabpot mentioned this pull request Aug 4, 2023
Closed
@fabpot fabpot merged commit 7ebccf7 into symfony:6.4 Aug 4, 2023
This was referenced Oct 21, 2023
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@stof stof stof left review comments

@fabpot fabpot fabpot approved these changes

Assignees
No one assigned
Labels
DomCrawler Feature FrameworkBundle Status: Reviewed
Projects
None yet
Milestone
6.4
Development

Successfully merging this pull request may close these issues.

[FrameworkBundle] Test assertAnySelectorText* functions
5 participants
@SVillette @stof @fabpot @nicolas-grekas @carsonbot