A better response to "How do I know then if the code works?!" might be to say, "No amount of unit tests can guarantee that your code works."
All tests are a cost benefit trade-off. You absolutely need them, but beyond a certain point you get diminishing returns. Writing useful tests is all about value, getting the most bang for your buck.
Testing simple accessors and "glue code" typically has little to no value. However, if it's the case that the "glue code" has a lot of churn, or something about it feels fragile, that it could break, a high level integration or acceptance test can prove very useful. Even if it doesn't always pinpoint the exact "glue code" that broke, you at least have broad coverage over multiple possible points of failure.
A better response to "How do I know then if the code works?!" might be to say, "No amount of unit tests can guarantee that your code works."
All tests are a cost benefit trade-off. You absolutely need them, but beyond a certain point you get diminishing returns. Writing useful tests is all about value, getting the most bang for your buck.
Testing simple accessors and "glue code" typically has little to no value. However, if it's the case that the "glue code" has a lot of churn, or something about it feels fragile, that it could break, a high level integration or acceptance test can prove very useful. Even if it doesn't always pinpoint the exact "glue code" that broke, you at least have broad coverage over multiple possible points of failure.
Very true.
Most (maybe all?) things in live, not just programming, have trade-offs.
If you don't stop to think about those trade-offs, you cannot make any good decisions. In fact, you are not even making decisions.
We are paid to think, or that is what I want to believe.
Thanks,
Dan