I work at an early stage startup. We evaluated testing vs velocity. Our conclusion was almost universally:

* BE tests are easy to write, catch lots of important bugs, and generally speed up development.

* FE tests are painful to write, rarely catch meaningful issues, and don't really save any effort - devs still need to click through a UI to make it's correct.

* E2E tests were even more painful to write. Likely caught more than FE tests, but not enough to justify their even more insane overhead.

----

Typescript does wonders for FE test coverage. The bugs we do run into tend to be silly oversights (empty arrays, FE <> BE type mismatches, etc). Annoying, but quick fixes. Not worth a 30% overhead on every feature to save 5% occassionally.

Omg...do not like where this conversation is going. Handing people untested software is ridiculous. At that point we might as well have cooks dip thier hands in raw chicken before making your salad or encourage machinists to dawn long flowing scarves.

People who don't test don't test because they don't know how. They are hacks.

> People who don't test don't test because they don't know how. They are hacks.

Or maybe they're just doing a different trade off. Do you unit test all of your shell scripts and jupyter notebooks?

If not, why is that? Is it that some code is either obvious enough or doesn't warrant having tests for it?

There's a spectrum of testing, from zero tests (which is fine for throwaway code), to testing a few key components and having end to end tests for the rest, to having 100% branch coverage. One should write enough tests that they're confident about the quality of the software that they're shipping, and no more, in my opinion.

Nit: it’s “don” not dawn.

Also hopefully interesting, the opposite of “don” is “doff”.

Because those are shorthands for “do on” and “do off”. Then again, don and doff are regular verbs — donned, doffed.

Why is everyone in this thread forgetting what tests actually do?

Tests force you to write better code. Code that is easier to change. Code that is more robust.

You don't need 100% coverage or perfect tests to gain this benefit.

A good test suite enables you to make large refractors safely and quickly.

The most scary refractors I've ever had to do are ones that involve large changes to code that has no tests.

Often those refractors that allow company level pivots require adding huge amounts of tests to a legacy code base before I can even get started.

Adding tests to code that has none is the worst. The code is coupled all over the shop and requires 100 times more mocking and stubbing to get under tests when you add this stuff retroactively.

Tests speed up development velocity and improve your codebase.

Just don't get stupid about it and you won't negatively impact startup performance.

I generally feel the highest value tests are at the lowest level (code with few dependencies) as well as end-to-end integration tests. It gets a little murkier in middle layers since alternate implementations of dependencies (aka mocks) need to be created, or one has to deal with complex setup of dependencies or in some cases re-testing the same logic that has already been tested at a lower level.

I'm not suggesting middle layer testing is not valuable, shouldn't be done, or to never use mocks, etc., it is just much more difficult and more creativity is required to add value in this area. For example, in some situations middle layer testing requires the creation of various kinds of utilities and frameworks in order to find a reasonable benefit vs effort sweet spot. Dogmatic approaches (such as mocking all dependencies in all situations) feel like they are productive at first but can end up being costly as each mock is an alternate implementation of an interface and doesn't necessary capture the behaviour of the concrete implementation.

I hardly ever do unit testing. It's almost always integration testing with code that uses real implementations against a testing db. This is only possible because my code is decoupled in the right places to enable this sort of no mock style testing.

I don't strive for 100% coverage and I hardly ever do TDD unless I'm working on something hard to solve.

Tests give me confidence and results in less time repeating the feedback loop. I might have a slower "coding speed" but I have fewer regressions during refactoring. Less bugs to fix while iterating. And less back and forth with stakeholders to ship something. Overall I'm way faster with tests than without.

This is the advice I give to junior developers:

1. Feel free to write tests that help you develop your thought or solution. Not all of those should be checked in

2. Ask yourself: “What test do you need to write in order to protect this code from your future self next year when you have forgotten everything about this?”