[PaulHoule]

It is the opposite.

Browser automation tests are horrifically expensive. Unit tests are cheap if (1) you don’t let them get expensive (yesterday I wrote tests a process that needed key pairs, I genned keys once and hard coded them) and (2) the design is appropriate.

One design might be untestable. Another design might sacrifice design for flexibility. There is another design which is testable and good in other respects.

The worst cost of tests is that they take a long time to run.

[budhajeewa]

I naturally think about (Or pencil.) what elements should be in a page, and how they should behave. That is easier to translate to browser tests.

Also, even if I write feature or unit tests to invoke some class methods, there's no guarantee that they'd be executed when a user performs some action in the page. To do that, I'd either have to manually check it (Bad, because its not repeatable.), or write browser tests anyway.

Edit: Typo

[PaulHoule]

I do it the other way around.

If the framework is correct in design and implementation then you can change something superficial and the odds are good that the change is superficial and it works.

If you are starting from the outside and working in it might seem easy to get started but you will fall behind in productivity compared to people who do the opposite.

I have frequently worked with testers and frequently those testers have chosen to automate their work and I am all for that; a dev doing the same might catch some errors that way but they may also encode conceptual mistakes.

[budhajeewa]

What if it is a single person project, or a small team with only devs having to manually test each other's work?

[PaulHoule]

All the more reason you can't afford browser-based automation testing and have to build quality in from the beginning. See

https://www.amazon.com/Quality-Free-Art-Making-Certain/dp/04...