Link following in Wallaby

Questions / Help
,
1

I’m trying to write a really basic Wallaby test to check that an anchor link navigates the user to the right page. My link:

<a href="/cases/new-case" class="button button__primary ">
  Add a new case
</a>

My test:

session =
  session
  |> visit(~p"/cases")
  |> assert_has(Query.link("Add a new case", count: 1))
  |> click(Query.link("Add a new case"))
  |> assert_has(..predicates to test new page ...)

The problem is that although the assert_has succeeds, and I can see that the link is visible in the browser, the navigation to the new page does not happen - even if I insert a sleep.

This seems like a pretty basic test automation, so I’m really not sure why the link follow is not working. I know I can just visit() the URL of the destination page, but in this test I want to text the UX of clicking on the link. But I have no hypotheses left to explore as to why the link is not being visited, and would welcome any suggestions.

I’m on Ubuntu, using chromedriver-120.0.6099.109 and an identical version of Google Chrome

2

Is there any more context you can share because that should definitely work.

3

@sodapopcan The additional context, I think, is to do with authentication. The route I’m testing requires user log-in. I’m following this pattern to set a browser cookie as though the user had logged in. From what I can tell, this is allowing me to successfully visit the initial page (/cases/, but not navigate to the second route /cases/new-case), even though both are normally navigable in one session.

I’m only trying the cookie-injection method because I’ve been seeing some non-deterministic failures when I create the same test but replicate the user logging-in at the start of the session. It’s all been a bit frustrating, tbh!

1 Like
4

hmmmm, that does sound frustrating. I can’t speak to the cookie method and just run the user through the log in process every single time and actually prefer to do so. I’ve never run into any non-determinism with this method. Did you figure out why it was happening? If not, that sounds like it could possibly be a symptom of an actual implementation issue.