On May 28, 2015 4:21 PM, "Jon Robson" jdlrobson@gmail.com wrote:
I suspect the idea is to lean more on our quality assurance infrastructure e.g. browser tests which I fully welcome.
The more developed they become the less chance of regressions making it to code let alone our projects.
When I joined 3 years ago we had no quality assurance infrastructure and now we've got things in a great place. They still need a little fine
tuning
but this should help us iron out the kinks by forcing us to rely on them more and push out better code.
Significantly better than three years ago, sure. However I would not use the phrase great place. There are still significant gaps in our coverage. For browser tests in particular Im given to understand that the asynchronous nature and somewhat high false positive rate make them not be taken as seriously as they should.
Fwiw, i have on several occasions recieved reports from users that I broke something (obviously i try to avoid that, but im far from perfect). I have never once had a browser test succesfully tell me I broke something in advanced (albeit it could be because i do backend things, but backend things do affect the front end when they explode). Occasionally the unit tests do, but i would still say there is a lot they dont.
Tl;dr: imo tests are great, but no where near replacing actual testing, at least for now.
That said, i dont think that the new deployment schedule will cause any problems, and is at the very least worth trying.
--bawolff
P.s. anyone remember writing code in the time between 1.16 and 1.17? You are all spoiled :p