Should I keep the default low level timeouts if my tests are slow? (40s - 1m20s)

You can override on a case-by-case test basis if you choose using:

Yes, I wanted to write the same but if the application is very slow probably all actions needs more time to execute. overriding every action method could be very troublesome, so increasing default timeout is not that bad in this situation.

Thanks for the replies! The issue is when the test breaks and I have to debug it: because is the test is marked as .slow(), when some element which has to be acted upon is missing, I have to wait for 90s until the test finally fails. So it's not like the actions per se need the timeout

Any more insights?

@yuriy_sng have same issue, increased timeout for tests but also timout for actions is huge,but I dont need it, have not found the solution yet...

@yuriy_sng Have you tried this ? use: { actionTimeout: 10000, }, in playwright-config?

It adds timeout to actions instead of 0 by default

So following the logic if element is detached or smth like this it should fail in 10 sec instead of overal timeout

@fotbee Yeah that's what I was considering, but reading "you should not need to change these" in the docs made me question if that was the best approach, hence this post

Another approach would be to dynamically increase the timeout using https://playwright.dev/docs/api/class-testinfo#test-info-set-timeout for some group of function. For example every time performing a login +5s, create new account +10s, verify email +10s...

I had the same dilemma with timeouts and asked a question here too. People suggested to add a setTimeout() for slower tests or slow(). However, what we did is we increased the global timeout (for now the value is 130000) and it looks like it's enough. The point is - our app is slow, we have many integrated components that we wait to load etc. So it's impossible to not change the defaults and just go with it. 🤷‍♀️ But I get your question, we too wanted to go along with the documentation and not increase anything in configs at all [I was referring in my post to industry standards if any exist at all].

Slow tests are alright. Sure it would be great if the app (and thus the tests) was faster and all, but getting some test automation is critical to optimize and avoid regressions.