3 ms·
> I even feel that if the code doesn't have unit tests in the first place the original developer didn't care I saw unmaintainable projects of very low quality
by Const-me 10y ago
> I even feel that if the code doesn't have unit tests in the first place the original developer didn't care
I saw unmaintainable projects of very low quality with near 100% unit test coverage.
I saw projects with outstanding quality without unit tests.
To me, presence/absence of unit tests means nothing.
> uses for example boost.filesystem
Why boost doesn’t change API when changing the implementation to something incompatible? If they did, you’d catch (and be forced to fix) most of those compatibility issues even earlier than unit tests — at compile time.
Also, unit tests are IMO nearly useless with IO heavy code like filesystem access. If you use mockups instead of actual IO, you won’t get those errors from the OS i.e. will test nothing. If you don’t, the tests will be too complex to deserve “unit tests” name.
> Nobody said anything about a waterfall.
A development model where you first design the entire system, then implement the entire system is waterfall. The approach only works well for some projects.
> But once it's stable
Many software projects evolve constantly: you stabilize your design, release a version, then based on e.g. market performance you redesign your system and create a next version of it.
Unit tests work well when you’re doing many local changes, when API stays stable and you only replace or fix the implementation. They are also useful when you code business logic, or lower-level code with lots of math (esp. SSE/AVX code).
However, if you have high unit tests coverage, API-breaking redesign is expensive. Unit tests might cause you stick to your initial 1.0 design, but because you need those new features you’ll start write hacks introducing technical debt. Even if you take your time, redesign, stabilize the design, and write new tests — this costs time + money.
Just like most other aspects of software engineering, unit testing is a tradeoff: improves something, worsens something else.