Just heard an interesting talk by Kevin Rutherford at Agile Manchester about connascence and how it can be used as a guide during the refactor part of the TDD cycle (red-green-refactor).
“Connascence of value”, for example, means that the test code and the production code are coupled by shared knowledge of a value. In other words, there is duplication of a value, such as a price or a limit or a quantity, and that duplication needs to be resolved by refactoring, thereby breaking (or at least weakening) the coupling.
There are 9 kinds of connaescence including connascence of value, of algorithm, of meaning, of execution order, and 5 more, and they can be ordered in terms of criticality. For example, connascence of value is more critical than connascence of meaning. Kevin suggests that if you learn to recognise the different types and tackle them in order of criticality, that it can help you progress through the refactor stage of TDD without getting stuck or going in circles.
It immediately struck me that there is a similarity here with the transformation priority premise. TPP seems to apply more to the “green” phase of the TDD cycle. When you have added a new test (“red”) you have made the test suite more specific, and now you need to generalise the code to make it pass the more specific tests. Uncle Bob noticed that the transformations you apply to the code tend to occur in similar patterns at similar times, and more importantly in some order. By identifying and ordering those transformations, does the “green” stage become a little easier to do without getting stuck if you can recognise what transformation should come next?
For example, a test that expects the answer “50” can be satisfied by code that always replies “50”. Add another test, thus making your test suite more specific, and you have to generalise the code to pass both tests, perhaps by adding a conditional.
Add another test, increasing specificity of the test suite, and you have to further generalise the code to pass the tests, perhaps by transforming the conditional into a loop.
If you become familiar with the idea that very often a conditional expression may survive a few iterations of the TDD cycle until a more specific test forces some transformation, and that the transformation is usually to a loop, could it make you go faster and more easily through the TDD process? By recognising a pattern and knowing the step that usually follows, do you have to think less? Does it make it easier to build the “instinct” that TDDers gain from years of practice and experience? Could it give a head start to those who haven’t spent years internalising the techniques?
If connascence and TPP capture some common patterns that experienced programmers instinctively use when doing TDD (and just when coding), can they be refined and cleanly expressed in a way that creates a more insightful degree of guidance than can be gained from simply saying “factor out duplication” and “write the code to pass the test”.
Are connascence and TDD alternate expressions of the same concept or are they distinct? Complementary? Can they be codified, even automated into static analysis tools or refactoring shortcuts or code completion suggestions?
Further work needed….