I am going to go ahead and say no, you should not write these kinds of UI tests before reaching market. In my experience, things change a lot in this regard before, during, and after initial launch of a product, and the overhead of changing the tests with every change is not going to be worth it.
Software development in the wild is all about tradeoffs and risk management, and the risks of creating too much overhead outweigh the risks of breaking the UI a few times. This post touches on this subject well.
I'd say focus on good monitoring practices early on as opposed to restrictive testing. It will take a while until the mushy parts of UX start to solidify and you need to take on the risks of slightly more brittle software in order to mitigate the risks of process overhead.
I'll echo exactly what Ben has said. Automated tests are great, when there are a lot of people working on something, or when it is a big company and there's a codebase that has matured. If you're building something with a couple of people or by yourself, I'd say don't focus on tests. Add some tests for any business critical parts that would be disastrous if it breaks, or as you're fixing bugs maybe add some tests (test to prove it's broken, and validate it is fixed with your change).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am going to go ahead and say no, you should not write these kinds of UI tests before reaching market. In my experience, things change a lot in this regard before, during, and after initial launch of a product, and the overhead of changing the tests with every change is not going to be worth it.
Software development in the wild is all about tradeoffs and risk management, and the risks of creating too much overhead outweigh the risks of breaking the UI a few times. This post touches on this subject well.
I'd say focus on good monitoring practices early on as opposed to restrictive testing. It will take a while until the mushy parts of UX start to solidify and you need to take on the risks of slightly more brittle software in order to mitigate the risks of process overhead.
I'll echo exactly what Ben has said. Automated tests are great, when there are a lot of people working on something, or when it is a big company and there's a codebase that has matured. If you're building something with a couple of people or by yourself, I'd say don't focus on tests. Add some tests for any business critical parts that would be disastrous if it breaks, or as you're fixing bugs maybe add some tests (test to prove it's broken, and validate it is fixed with your change).