I was one of the people who called out @cypress_io . Building software is complicated and it's because of this, the questions we ask and advice we give are so important.

X: Did @cypress_io intend to promote bad practices?
me: No, I don't believe so
X: So what was your problem? https://twitter.com/filip_hric/status/1296774887634350082

2/ me: It was the reason given for why it's ok to use them

me: Anyone who's worked in web dev will have a connection with this list of possible reasons why their checks fail.

3/ me: To imply that the solution to this was to 'refresh your browser like your customers would' is worrying and came across quite flippant.

X: That's what users do though right?
me: It is, but when is it acceptable for them to have do that?

4/ X: I guess when something happens that's out of their control?
me: I think that's a fair distinction. Is that a principle by which we should develop the application too?

X: I guess so, but there are always trade-offs when building software, aren't there?

5/ me: Absolutely, we should be making conscious decisions all of the time about what is acceptable.

X: So what's the problem here?

6/ me: As a software tester, under many pressures, their reasoning could make it very difficult for me to help the team meet the principle you defined earlier.

X: How so?
me: Scenario 1, I write a test that occasionally fails because the submit button isn't rendered in time.

7/ me: I submit the bug and an under pressure dev asks me if Cypress supports retries. I say yes. The dev asks me to turn them on. So I do. Now the test 'always passes' and the bug is closed.

X: That's good isn't it?
me: Not really.

X: Why?

8/ me: Because the team were under pressure to ship. It turned out one small bit of js would get stuck in a loop, meaning that for some customers the submit button never appeared and they had to hit refresh.

X: Did that impact a lot of customers?
me: It turns out it did.

9/ After a few hours of releasing, we noticed the number of refreshes on this page went through the roof. Looking into it further we saw it was mostly on slower devices.

X: But you fixed it?
me: We did, but not before our customer care team got hit quite hard with calls.

10/ me: You see it ended up impacting 2 out of 3 page hits. We have a lot of customers.

X: Yeh ok, that must've required a bit of explaining?
me: It did, but lesson learned. Sometimes 'speed' isn't always what we should optimise for.

X: So we shouldn't use retries?

11/ me: That's not what I'm saying. Feel free to use them, but use them sparingly and with intent. Automated checks will never tell you things 'always work'. Retries will likely undermine this message further.

12/ Yes this is a relatively contrived example but I've seen far worse. Application stability IS very important and that doesn't always have to mean APIs and servers. An over focus on 'speed' and shipping fast can hugely undermine your mission.

13/ All of the tools we use have their drawbacks and so does all of the different ways we use them. @Cypress_io is an amazing tool, made by some incredibly talented and amazing people. We all make mistakes and some aren't recognised as them until afterwards.

14/ But we should always do our best to ensure that we stick to core principles. @Cypress_io exists to help teams deliver the best software possible, which on the whole it does and it does well, I'm a massive fan.

15/ But because of its reach and influence, I believe that @Cypress_io also have to be responsible for the impact their influence 'can' have. The rest of the documentation comes with a lot of care, on this occasion I believe that care fell short.