retrofitted tests (being usually written against the nominal use case's specification) help spot anomalies in the observable effects of the running application
but unlike tdd testcases written before code (possibily more than one for each line of code, for the correct as well as the undesired behaviour), they are not in direct correspondence with the code they test
thus they dont guarantee that the code is minimal (only the one "necessary and sufficient" to make the test pass ie satisfy specifications - minimality which in turn typically makes the code cleaner and more readable) nor that you cannot "change a LoC without at least one test faling" (which is the imperative with pure tdd)
thus dont guarantee against possible hidden bugs
and, they dont account for code documentation - unlike tdd testcases which should possibly suffice to understand the program's internals (since they're a programmatic embodiment of the program's specifications)
so you spend a long time (possibly longer than with tdd - since to get a working prototype you rush development ) adding stuff that wont, by itself, make the rest of the code more streamlined, more readable, directly documented or directly mapped over working specs - which you'd possibly get directly using TDD... i fail to see the point of it...Yes its takes a long time to get coverage but it just involves adding tests for any new code.
of course, TDD like other forms of Agile development isnt perfect, far from it - but if anything it gets you code at every iteration ("early release") that you can assume to work (ie code you dont necessarily have to go back to for bugfix testing etc, later) as soon as the iteration is complete (all test passing, assuming tests are correctly written themselves), and is inherently documented and minimal, since the earliest iterations
OTOH, to get this you have TDD should be used from the start , hence canonical's decision
Sure I 100% agree with you if you are *starting* a new project TDD makes a lot of sense. But (and I should have made this point in my last post) TDD is not a reason in itself to start a project from scratch when you have an existing project that has reached a stable state and you are not going to be doing anything a whole lot different.so you spend a long time (possibly longer than with tdd - since to get a working prototype you rush development ) adding stuff that wont, by itself, make the rest of the code more streamlined, more readable, directly documented or directly mapped over working specs - which you'd possibly get directly using TDD... i fail to see the point of it...
In the case of Mir if TDD is so important than why not push for it to be used by the Wayland project rather than reinventing a stable project.
Last edited by timothyja; 03-07-2013 at 11:16 PM.