Questions that I want answers for...
1) Propose one or more mechanism, which could be used to extend TDD to estimate the level of gold plating that exists in an arbitrary Java program.
2) What estimations would your mechanism provide the quantity the level of gold plating?
3) What evidence can you provide (if any) to justify or argue that your proposal is viable extension to TDD, which provides a meaningful quantification.
I don't think it is even possible to do a mechanism that extends TDD to do it.
TDD is mainly about design and it is used after planning your application, not to plan it!!
Gold plating usually happens when you did any mistakes when writing the user stories (I am assuming that your stories are small enough that each feature is a story). So it is not a matter of design (coding) but a matter of planning!
There might be a way to match up tests (either test cases or test suites) to required features or user stories.
For example, if you have n required features and 1 test suite per feature, you would expect to obtain n test suites. If you have more than n test suites, you might have implemented or are possibly going to implement (since the tests are written before the feature, you might have written the test but not implemented the feature).
The only downside is if you do things incrementally - you might have n required features, implementing m in an iteration, there's no way to just look at the numbers to say that all m implemented features are required features - you would have to write tests for ALL features first.
I would not place to much emphasis on this technique - and I highly doubt it would work in practice. It requires you to specify that you have n tests per feature or put all tests of a particular feature into a test suite. It might be too limiting or imposing on your developers. On top of that - it might not even work. A developer could write tests for an unrequired feature and put it in the test suite for a different feature.
In TDD you write the test first and only write as much code to make the tests pass. As soon as a test passes, you stop writing code, thus avoiding gold plating.
You cannot completely avoid gold plating with TDD though, since you still face a risk of writing to many tests, not sticking to just the relevant ones.
Although TDD would be a valuable tool in the process of preventing gold plating, it doesn't do it on its own. Principles like YAGNI and small focused iterations that deliver the functionality required by the end user and nothing more are more about preventing gold plating. What TDD can do is focus a design out that process which is usable for the next iteration without feeling like you have to rewrite all the code to accommodate the next feature, or feel like every change brings with it more work in regression bugs than was gained in new features.
TDD can help with Gold Plating at the unit level, in that if the code needed to pass the test is all that is written, many different scenarios and potential what-ifs can be left aside until the tests justify them. It certainly helps me in that area. But it isn't enough to prevent large scale design ambitions with the attendant focus on only getting out the user story that is scheduled for this iteration and nothing more.
can someone explain ques 2nd and 3rd in more detail: 2) What estimations would your mechanism provide the quantity the level of gold plating? 3) What evidence can you provide (if any) to justify or argue that your proposal is viable extension to TDD, which provides a meaningful quantification.
TDD won't prevent gold plating, but it can help remove some of the inclination to engage in it.
An interesting thing I've found with my TDD-written code is that it tends to be very loosely-coupled, with a lot of abstractions, and yet has virtually no generalizations. All of the actual code tends to be relatively specific, it just only talks to other code via abstractions.