> the other senior dev might not be a superman of similar competence
Superman? Any experienced developer should be able to work with other people’s code. If you can’t, you’re either inexperienced, or need to learn the language/frameworks used.
> look there's a unicorn!
IMO 70% of third-party code is crap, regardless on unit tests. Moreover, nearly 100% of the third-party libraries comes with a license saying “provided as is, without warranty of any kind” or similar.
When using any third-party code, you have to carefully test whether it fits your particular purpose. You’ll need to test that code as a part of your system, feeding your data, and measuring the performance characteristics you need. Unit tests don’t help with that.
> You have to think this through starting at the design level.
Waterfall model only works if you’re building a space shuttle or similar.
Architect isn’t a prophet. Design changes through development as requirements change. Between major versions, they can change dramatically. Also there’re external factors that often affect your design: language, it’s runtime, host OS, sometimes even CPU architecture — they all change.
Eventually, you gonna need to update your design even if at the time of your version 1.0 it was just flawless.
>> Superman? Any experienced developer should be able to work with other people’s code. If you can’t, you’re either inexperienced, or need to learn the language/frameworks used.
You'd think so, but thats not always the case. There are many boundary cases and "gotchas" that might not be even visible in the code. (I.e. the stuff that isn't there). Secondly the follow-up dev might be not that interested in code quality. Personally I even feel that if the code doesn't have unit tests in the first place the original developer didn't care and the shop didn't care then why should I bother?
>> Unit tests don’t help with that.
Ofc they do. If I write a class that uses for example boost.filesystem, and I have my unit tests that test my class. I upgrade my copy of boost. Ofc, my unit tests won't tell me that some other part of boost.filesystem has regressed but at least if some API that I'm using has changed and behaves differently I have a chance of catching it.
>> Waterfall model only works if you’re building a space shuttle or similar.
Nobody said anything about a waterfall.
>> Eventually, you gonna need to update your design even if at the time of your version 1.0 it was just flawless.
Personally I don't rush to write the unit test immediately, but only after I've put a bit more code together and verified that the design works. Call it a gut feeling or intuition. But once it's stable I write the unit tests. That doesn't mean that I'd ignore the "testability" aspect when I do the design. Quite the opposite it's an important aspect of the whole process.
> 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.
Superman? Any experienced developer should be able to work with other people’s code. If you can’t, you’re either inexperienced, or need to learn the language/frameworks used.
> look there's a unicorn!
IMO 70% of third-party code is crap, regardless on unit tests. Moreover, nearly 100% of the third-party libraries comes with a license saying “provided as is, without warranty of any kind” or similar.
When using any third-party code, you have to carefully test whether it fits your particular purpose. You’ll need to test that code as a part of your system, feeding your data, and measuring the performance characteristics you need. Unit tests don’t help with that.
> You have to think this through starting at the design level.
Waterfall model only works if you’re building a space shuttle or similar.
Architect isn’t a prophet. Design changes through development as requirements change. Between major versions, they can change dramatically. Also there’re external factors that often affect your design: language, it’s runtime, host OS, sometimes even CPU architecture — they all change.
Eventually, you gonna need to update your design even if at the time of your version 1.0 it was just flawless.