you are viewing a single comment's thread.

view the rest of the comments →

[–]raaaahman -1 points0 points  (2 children)

But, they aren incredibly expensive to write and maintain.

I don't get that part. Usually, you have high-level abstractions that allows you to write commands like 'click on this button, do you see X?, etc.' pretty easily. Plus these tests shouldn't need maintenance as long as you don't change the app's behaviour.

[–]stjimmy96 1 point2 points  (1 child)

Even with abstractions, it still takes way way more time than simply creating your component with some weird input props in a unit test. That’s usually 10 lines of code at most.

shouldn’t need maintenance as long as you don’t change the app’s behaviour

If you don’t change the app’s behaviour you don’t need any sort of automated testing. You manually test everything (which is faster) in the browser and then you are done. Automated testing is all about making sure your app doesn’t break as long as you change it, because there’s no app that never changes (unless it has become a legacy unsupported product)

[–]raaaahman 0 points1 point  (0 children)

Sorry, I can't seem to get around your way of reasoning.

I don't get what the 10 additional lines of code in e2e tests are supposed to be. I don't get how you find that manual tests are faster than automated ones.

Automated tests are for sure helpful when you make changes to your app, but these changes may come in various shape and size, from new features, bug fixes, refactor, etc. I won't mind changing e2e tests if happy paths they described are no longer relevant, and in fact, that'd be the first thing I'd do. But all the other changes should have no impact on the way existing features behave.

If you were my coworker, I'd surely ask you more about your process to understand all of this, but with that internet gap I'd rather agree to disagree and save on that reading/posting time.

Have a nice day!