David introduces Part 4 explaining that nothing comes for free, including Test Driven Development. Although TDD doesn’t force you to do anything he feels it nudges you into doing many things.
He objects to the notion that you shouldn’t write a single line of production code without a failing test. He’s seen a culture where having four times as much test code as production code was seen positively which he’s never agreed with because he feels it is over-testing. He says Behaviour Driven Development is an improvement over testing inidivdual methods but this test code still needs to change when the implementation changes.
David says if you have to change four lines of code for every line of production code, something is not right, so he asks at what point is the ratio right?
Kent says JUnit had 100% coverage and he didn’t feel that was overtesting, but he believes in the idea of too many tests. He says his cousin came up with the idea of delta coverage: what each test adds uniquely that no other test provides. No delta coverage means you can probably delete the test. He sometimes writes scaffolding tests that he later deletes.Some people say you can’t delete tests but of course you can and should if it’s not giving you anything useful. Kent says coupling comes with costs and you need to get benefit for it if you’re going to accept those costs.
Martin says he is sure that code is sometimes over tested but he isn’t worried unless the amount of over testing is high. He likes to ask himself “If I screw up this line of code, is a test going to fail?” Sometimes he comments out a line of code to see if it is covered by any tests. He says only test things that could break – don’t waste your time testing simple getters for example.
Kent feels that the ratio of test code to production code is a bogus metric. He says he watched Christian Glazer write compiler code which had four lines of test code for every line of production code and his code was “absolutely rock solid”.
David says there are lots of declarative statements in his rails code that have not broken enough for him to feel he needs unit tests for them. He says you don’t need to have nearly 100% code coverage.
Martin agrees and says you have enough tests when you can confidently change the code without worrying that you might screw something up. He says it’s a sign that you’re spending too much time on unit tests when it’s taking you longer to change the tests than to change the (production) code.
David says there’s a different tuning for a consulting team and a product team – developers handing over to an unknown group of developers can be almost paranoid and feel they need to bolt everything down and over-test whereas production teams can be happy with 60 or 80% coverage.
Kent says TDD is not necessarily something that you want to do all the time but once you’re able to do it you have a wider range of options for your workflow. He agrees that different audiences involves different trade-offs.
David says in the old days documentation was considered essential before coding could begin (at the top of the authority chain) and that this notion was generally rejected. More recently tests are sometimes considered “top of the authority chain” with the tests acting as documentation over an above the actual production code, which David feels is just as bad.
David also likens “red – green – refactor” to “have fun – play video games – eat your vegetables” i.e. not enough time end up spent on refactoring.
Kent says he just went through an experience of throwing away an entire implementation but keeping the tests and reimplementing from scratch and poses a question to the viewers what situations would you rather throw away the production code rather than the tests and vice versa?
Martin says he’s found that some developers are more interested in building the test harness than the production code, and that tests are just a means to the end of getting valuable stuff delivered to the users. He says under refactoring tends to be due to lack of experience and skill and this isn’t a problem with more skilled developers.
Kent says it’s a harder sell to say you’ve made progress on a design by refactoring existing code that was already passing all its tests.
David says the value of refactoring can’t be reduced to a number. Some things that can be reduced to a number are speed, tests and ratios. As humans it’s tempting to focus on the quantifiable. Quantifying the quality of a design is really hard and really subjective. David feels test speed coverage and ratio are much less important than the clarity of the system. He says just being aware that it is possible to get sucked into spending too much time focusing on things like test speed and coverage can really help, and that he’s reserved a special place in hell for anyone who forces others to use cucumber. David alleges that TDD is put on a pedestal because of it’s successes and considers TDD to have won the battle by being used almost everywhere.
Martin disagrees saying many companies still lack any form of automated tests and focus on testability is not the case in any of those companies.