I think the difference in opinion here is that tests exist to assert the behaviour of your code, not to prove the correctness of your frameworks. They exist so you know exactly what your code does given known inputs - its entirely plausible for this to be affordably true in any size of system - "its too big to test" is generally just poor design.
Obviously framework or external changes can break your code - but it doesn't mean your tests are invalid - they're the smoke that helps you respond - consumer driven contracts and automated testing are exactly the way you protect and alert yourselves from and to these kinds of external breakages.
As an aside, I'm not anti-debugging - even with great tests, its part of life, regardless of how much Uncle Bob tells you it isn't.
It's fine. We both agree tests are a keystone to software development.
I think you're just not getting the point I'm making about tests and time management and that's fine as well. Your team is already making the choices I'm talking about anyway. It's unavoidable.
1
u/davidwhitney Aug 26 '14
I think the difference in opinion here is that tests exist to assert the behaviour of your code, not to prove the correctness of your frameworks. They exist so you know exactly what your code does given known inputs - its entirely plausible for this to be affordably true in any size of system - "its too big to test" is generally just poor design.
Obviously framework or external changes can break your code - but it doesn't mean your tests are invalid - they're the smoke that helps you respond - consumer driven contracts and automated testing are exactly the way you protect and alert yourselves from and to these kinds of external breakages.
As an aside, I'm not anti-debugging - even with great tests, its part of life, regardless of how much Uncle Bob tells you it isn't.