3 ms·

IMO if your implementation is that unstable (you mentioned the UI/workflow changes fast) it isn't worth writing a test for it, but also, I don't think it shoud

IMO if your implementation is that unstable (you mentioned the UI/workflow changes fast) it isn't worth writing a test for it, but also, I don't think it shoud be released to end-users because (and this is making a big assumption, granted), it sounds like the product is trying to figure out what it wants to be. I am a proponent of having the UI/UX design of a feature be done before development gets started on it. In an ideal XP/agile environment the designers and developers work closely together and constantly iterate, but in practice there are so many variables involved in UX design and so many parties that have an opinion, that it'll be a moving target in that case, which makes development work (and automated tests) an exercise in rework.

rtpg 2y ago
I think there's a great balance here in these environments: - write tests as part of figuring out the implementation (basically: automate the random clicking you're doing to test things anyways) - Make these tests really loose - Just check them in Being unprecious about test coverage means you just write a handful of "don't blow up" tests for features, that help you get the ball rolling and establish at least a baseline of functionality, without really getting in the way.
happysadpanda2 2y ago
Chiming in as an end-user of software: please try to minimize the amount of times I need to re-learn the user interface you put in front of me.
- happysadpanda2 2y ago
  Aaaaaaand I replied to the wrong comment, mea culpa!
softfalcon 2y ago
I agree with you that the ideal is to have UI/UX work resolved before starting dev work. In my experience, this has never happened. I’ve moved around hoping that somewhere, leadership has fixed this problem and nope. It never happens. There are just too many unknowns and never enough time for design to stabilize. It’s always a mad dash to collect whatever user info you can before you slap together a final mock-up of the interface and expected behaviour.

rtpg 2y ago

I think there's a great balance here in these environments: - write tests as part of figuring out the implementation (basically: automate the random clicking you're doing to test things anyways) - Make these tests really loose - Just check them in Being unprecious about test coverage means you just write a handful of "don't blow up" tests for features, that help you get the ball rolling and establish at least a baseline of functionality, without really getting in the way.

happysadpanda2 2y ago

Chiming in as an end-user of software: please try to minimize the amount of times I need to re-learn the user interface you put in front of me.

happysadpanda2 2y ago
Aaaaaaand I replied to the wrong comment, mea culpa!

softfalcon 2y ago

I agree with you that the ideal is to have UI/UX work resolved before starting dev work. In my experience, this has never happened. I’ve moved around hoping that somewhere, leadership has fixed this problem and nope. It never happens. There are just too many unknowns and never enough time for design to stabilize. It’s always a mad dash to collect whatever user info you can before you slap together a final mock-up of the interface and expected behaviour.