Automated tests are no different from any other software we write. They play on the same playing field of priorities as anything else. You have features to spec out, designs to make, bugs to fix, requirements gathering meetings to have, feature flags to configure, etc. etc. etc. To be able to prioritize these activities, you need to know the cost of doing nothing and the benefit of getting it done. And when it comes to prioritizing, you're not saying you "won't" do something, you're just saying you'll do one thing first. So it can also help to know the relative cost/benefit of doing it later vs the cost/benefit of doing it now.

Let's take a few different scenarios.

1. A bug prevents the user from changing their bio if they don't have an avatar first.
2. Your product checkout flow is not covered by tests.

For the bug, the cost is an unreliable UI for the handful of users who don't have their avatar uploaded out but want to change their bio. Not a great experience.

For the checkout flow, that's pretty serious. Any change to the code that touches that flow could break the checkout flow (potentially costing real money for the seller and valuable time for the buyer).

I think for that, let's prioritize adding a test first, and then fix the bug.

Ok, another scenario.

1. You're a startup and you haven't actually started selling your product yet because it's not quite feature complete enough to be useful. You're running out of money.
2. You just wrote a small function to calculate the distance your scrollable list needs to scroll as the user presses the ArrowDown key and you're trying to decide whether to test it.

For goodness sakes! Skip the test, get your product shipped and sell that thing! Your money is burning away 🔥💵🔥

That said, you might find that your demos to potential clients aren't going well because your engineers constantly ship broken code. In that case, write one or two quick and simple E2E tests for the common flows your demos take and run that before you merge any code.

Let's try one last scenario. Just for kicks.

1. You just finished implementing a new feature allowing the user to create a playlist of their favorite songs. You're wondering whether to add tests.
2. You saw an amazing font and editor theme in a live stream from your favorite dev and you want to ask them what it is so you can try it out.

😐

What I'm trying to get across in this post is that testing is no different from any other thing you can do with your time. Consider the costs and benefits, and act accordingly. Keep in mind that tests are the gift that keeps giving.

Good luck!