All things in moderation, I suppose. 800k+ lines is a lot of unit test code, even for a big monorepo, and deleting that much
could be justified if there are still a solid core of better quality unit tests left over. Now, if they really meant
all unit tests, that's a bit more suspect, but maybe they still have a solid core of integration and other higher order tests, which could make the decision still somewhat sensible, on a cost-benefit basis.
> Online I’ve seen instances where developers are proclaiming that all of their tests will be end-to-end. So we’re trading tests that are cheap with tests that are slower, need a running system and fail intermittently. An end-to-end test belongs at the top of the pyramid and when you move everything there, it gives you less coverage at a higher cost and topples over.
E2E tests can definitely be fragile, but I've definitely also seen cases of unit tests being fragile too: they try to go way beyond the scope of the "unit", and end up failing inconsistently for all sorts of benign reasons (e.g., leaking state between tests), wasting time. When you get into those kind of situations, just declaring unit test bankruptcy is a little tempting. But there's got to be some balance.
> Online I’ve seen instances where developers are proclaiming that all of their tests will be end-to-end. So we’re trading tests that are cheap with tests that are slower, need a running system and fail intermittently. An end-to-end test belongs at the top of the pyramid and when you move everything there, it gives you less coverage at a higher cost and topples over.
E2E tests can definitely be fragile, but I've definitely also seen cases of unit tests being fragile too: they try to go way beyond the scope of the "unit", and end up failing inconsistently for all sorts of benign reasons (e.g., leaking state between tests), wasting time. When you get into those kind of situations, just declaring unit test bankruptcy is a little tempting. But there's got to be some balance.