Focusing on integration tests: oh, the test fails, something is wrong somewhere... I will debug all layers for the next week, as we simply don't have too many tests covering the internal code.
I like to have both.
I like to have both.
In that context, are integration tests checked automatically the same way, say, Rust would error out on unhandled cases? Or is this left up to developer (who I assume is always writing this stuff at the last possible moment with the least possible focus)?
I think pleasecalllater's point is that without unit tests, you'll spend a lot of time just pinpointing the bug, since it could be anywhere in your module (which unit tests would cover), not just at the interface to other modules (which integration tests cover).
- run fast (<10s)
- run on your local machine
- run on your local code (including uncomitted diffs)
... whether they're called "integration" or "unit" tests doesn't matter, as they will detect regressions at the earliest possible time.
Unit tests might guarantee smaller code search area (because maybe the failing test only executed 1% of the code), but if running "git stash" makes all the tests pass again, I have a pretty good confidence about where the error lies.
So your codebase probably doesn't solve the problems and use the stacks most of us solve/use.
Why not?
> and use the stacks most of us use
Probably. Or at least not use them the same way.
I am consistently amazed by the time even unit tests take when I join projects. If they have them.
And those unit tests are usually also at least part broken and very incomplete. I would argue those phenomena are closely related.
The unit tests for one of my projects typically run in the ~1 second range, meaning that I can, and do, run them as part of the build process. A build is not complete until the unit tests pass.
This includes Postscript/PDF interpreters, so it's not just testing completely trivial stuff.
(Just checked: currently 3.9s real for 1498 tests across 9 projects, so a bit on the slow side overall)