Release v2 of gem #31
Conversation
- Run in random order so no dependencies are uncovered - Reset sessions after each test - When the order includes patching BEFORE running firefox tests, a couple of blank keys are added which made the subsequent tests fail. This is now fixed by using a lax(er), rspec matcher
…mpliance, so we need to re-tighten this restriction
…melcasing won't work otherwise
|
So I've learnt two new things @mrdaniellewis order random is a must in every project. |
| @@ -43,7 +48,7 @@ def capabilities | |||
| # This is required to make local drivers work exclusively with Safari TP | |||
| # This is required in V13 of Safari as the driver there is notoriously flaky | |||
| # In V12 it doesn't hinder it | |||
| # We don't support Safari V11! | |||
| # Safari V11 is unsupported. | |||
There was a problem hiding this comment.
I wanted to use Safari 11 in the Casebook smoke tests, as we still have some users. But yes, it was completely broken. Just ended up using 13.
There was a problem hiding this comment.
Funnily enough safari have basically said v12 is also "unsupported" so technically both are unsupported. But then you get into a minefield.
The safaridriver v12 I consider to be more performant and accurate than the v13 one. Primary reason being the v12 driver was one that contained both JWP and W3C stuff, and I theorise (It's closed source), that there are fallbacks e.t.c. in there that make things "work better"
safaridriver v13 just fails and falls over so frequently it was a nuisance when I first joined, so I just reverted to using safaridriver v12 again.
I'm midway through trying to get safaridriver v14 to work reliably, but outside of using it sporadically, it's falling over a lot (Although I believe that may be more browserstacks end).
|
We do the random order in the unit tests, but not the feature tests 😬, probably should change that |
Updated some comment docs and release v2