My opinion is that people write tests like this because of the setup phase. If the testing is not done right, if the abstractions are in the wrong place, or they are wrong, or your module seams are not where they should be, it can be really costly to set up the world for a test, so that is why people bunch up multiple assertions in the same test. You see this a lot in E2E tests as well. I think altogether these experiences from writing incorrect test suites lead to this learned behaviour.
One addition I would make for such tests, if the test framework allow it, is to change all earlier asserts to assumes. That way if an earlier step fails, all tests that depend on that step will show as inconclusive, making finding the actual failure easier.
Run on tests, in some form, serve to confirm non-atomic design characteristics. Secondary guardrails, as it were. If a change fouls a unit but not a run on, something is wrong (and vice versa).
My opinion is that people write tests like this because of the setup phase. If the testing is not done right, if the abstractions are in the wrong place, or they are wrong, or your module seams are not where they should be, it can be really costly to set up the world for a test, so that is why people bunch up multiple assertions in the same test. You see this a lot in E2E tests as well. I think altogether these experiences from writing incorrect test suites lead to this learned behaviour.
One addition I would make for such tests, if the test framework allow it, is to change all earlier asserts to assumes. That way if an earlier step fails, all tests that depend on that step will show as inconclusive, making finding the actual failure easier.
Run on tests, in some form, serve to confirm non-atomic design characteristics. Secondary guardrails, as it were. If a change fouls a unit but not a run on, something is wrong (and vice versa).
I hope people still think about this kind of stuff now that we’re in a new age. Quality matters more than ever.