> It's important to note that having high test coverage doesn't make code good. Sure, but low test coverage doesn't make it good either. Coverage is a metric a

> It's important to note that having high test coverage doesn't make code good. Sure, but low test coverage doesn't make it good either. Coverage is a metric and like any metric, it (1) needs to be assessed with judgement and (2) becomes useless when it's used as a target rather than a measurement. > Tests have nothing to do with code quality. All they do is verify that the code works. Well to start, Fowler notes a distinction between external and internal quality. External quality is "does it work from the end user perspective?", which can be verified by tests -- you note integration tests in this role (acceptance tests, feature tests, user tests, behaviour tests, whatever you choose to call them). In the external quality case, verifying that the code works is a large fraction of quality. Your argument, I think, is that internal quality is unaffected by testing. I don't agree: in my experience the needs of simple testing create constant design pressure on the production code, most of which makes it easier to create future changes. Though as noted at the top of the thread: expertise still matters. Writing better tests and better production code are skills.