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

Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.

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

bash

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:

text

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

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

A failing URL assertion showing the expected pattern and the received URL ending in /signin — Five scenarios, one cause: the application redirected to its sign-in page

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

ui smoke pool

asked by Yusuf Demir

4 answers

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:
bash
```
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:
gherkin
```
  @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.
answered by Reeta NandalSDODS team
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.
answered by Rafa Garrido
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.
answered by Priya VenkateshSDODS team
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.
answered by Tomas BrekkeSDODS team

Know the answer?

Wrap commands and output in triple backticks and they will render as a code block.

Checking whether you’re signed in…

Have a different question? Ask it.

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

4 answers

Know the answer?

Related