But in general, I agree!
276 karma · joined August 20, 2018
Blog at https://jameswilson.codes
But in general, I agree!
Edit, father who has seen Paw Patrol in lots of different regional versions on different streaming service.
Very much enjoying doing some rails after years of JS
But as they mention, it can be hard to install ruby/python. Node is normally much easier. I've given up on getting react native going on my personal laptop, and I do react for a loving.
Source: years as a workplace rep in UK school under austerity government cutting public sector pay and pensions, plus 3 years as a branch secretary.
I tend to think of them clicking things and waiting for a response then moving on to the next thing when that happens (or failing the test when it doesn't) which seems to fit well with an async model.
Cypress _does_ do a lot of magic behind the scenes to stop you explicitly using async/await or promises in the code... Which occasionally bites it.
Especially when you have to use a .then to use values you pull from the Dom.
Having said that, I find parts of it v confusing (although not the asyn stuff) especially around assertions - there seem to be multiple ways to do things and I'm never clear which is which.
As a sibling reply said, try to write cypress (or other similar product) tests not to rely too much on layout - I use html data attrivutes rather than text or Dom based selectors, so the tests can survive most redesigns, and if they don't, it's because the user journey has changed enough that we _should_ be changing the tests.
That said, I find checking for specific values in the page against other page values to be really difficult so if you're doing that with the table... good luck!
You could design your own tracks and I remember finding a glitch if you raced the indycar at top speed towards the biggest ramp where it would fly into the air and be bound only by the top of the coordinate system. Great times (and I don't even like car games...)
They'd expect you to be wanting an increase in order to move?
I think I should have explicitly rather than implicitly defined class as more broad than just 'has a lot of money' - these examples are kind of 'working class but became successful' rather than 'upper class'?
Edit - and then used that definition rather than just saying The Rich
Patch - a build we do to be deployed to clients test environment that we don't control
Minor - a prod build for client
Major - reserved for when the client demands a complete redesign of the app
It works for us, for this project... And of course nobody else is depending on it
And you're right that screen sizes can mess stuff up, Firefox/chrome mobile view on devtools doesn't always tell the full story... Got something working there and it was broken on my actual phone.
I stand by my comment if you don't have to do IE < 11 though.