On May 28, 2015 4:21 PM, "Jon Robson" <jdlrobson(a)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