← All questions

First UI run: five scenarios fail on the sign-in page, but the API layer was green

51votes

Working through the workshop on my own checkout of the sample app. The API layer passed straight away. Then the browser:

bashCopy

sdods run -p rwa-raw -e local -l ui -b chromium -t @smoke

Five failures, and as far as I can tell they are all the same failure:

textCopy

Error: expect(page).toHaveURL(expected) failed

Expected pattern: /\/\*/
Received string:  "http://localhost:3000/signin"
Timeout: 10000ms

The app is definitely running — the API scenarios hit it. Is the generated suite just wrong?

uismokepool

YDasked by Yusuf Demir201 · 12 Jun 2023

4 answers

• 62votes✓

  Accepted answer

  The suite is not wrong; it has not been given an account. Every one of those pages is behind a login, so the application redirected to /signin and the URL assertion saw the redirect target.

  Give it a user and the same five scenarios go green:

  bashCopy

  sdods auth capture -p rwa-raw -e local
  sdods auth list -p rwa-raw -e local

  Then tag the scenario with the role it needs:

  gherkinCopy

    @smoke @user:standard
    Scenario: The personal page loads
      Given I navigate to the "personal" page
      Then the page URL should contain "/personal"

  Login happens once per pool user and the browser state is reused, so this costs you seconds across the whole suite rather than a login per scenario.

  The reason the API layer was green is that those endpoints did not need a session, or the suite already had a token for them. Layers fail for different reasons: api points at the endpoint or the port, ui points at the page, the locator or the login.

  RNanswered by Reeta Nandalmaintainer41,280 · 12 Jun 2023
• 19votes

  One extra thing to fix while you are in there: look at the expected pattern in your own paste. /\/\*/ is what analysis wrote when it could not tell what the route was — it is asserting the URL contains /*, which is nothing.

  Once the login works, correct the assertion to the route the page actually has. Otherwise you have a scenario that goes green and checks nothing, which is worse than the failure you have now.

  RGanswered by Rafa Garrido12,996 · 13 Jun 2023
• 16votes

  Worth reading the pool guide before you scale this up. @user:<role> leases a user from the pool for the scenario, so two scenarios that both want standard do not fight over the same session when you raise workers. The role has to exist in tags.roles or lint rejects the tag.

  PVanswered by Priya Venkateshmaintainer29,604 · 14 Jun 2023
• 8votes

  Coming late — if you have the login working and a scenario still fails, stop reading the URL and open the trace. A post-login failure is a locator or a step problem, and the trace shows you the page as it was at the failing step instead of asking you to reconstruct it.

  TBanswered by Tomas Brekkemaintainer33,915 · 4 Jul 2023