On the Italian Extreme Programming mailing list there was a discussion originated from my TDD live demo held on the Second Italian Agile Day (more on this in a later post). At a certain point of the discussion it came up the idea that TDD and OO design are not necessarily tightly connected. Well, I disagree and here’s my take on that.
Let’s put it simple: there is no TDD without refactoring, that is refactoring is a constituent part of TDD, not something beyond TDD that I can consider as an option. TDD micro-cycle is: test => red bar => code => green bar => refactor => green bar. If you don’t refactor you are not following TDD.
Let’s consider now that refactoring is OO. There is no refactoring without OO. The smells that you recognize into code are another symptoms for rigidity, fragility, immobility. Every refactoring move is justified by 3 criterias:
- enhance code readability
- reduce coupling between classes/modules
- enhance cohesion of classes/modules
Apart from readability, every refactoring move if correctly applied brings to OO design. What means correctly applied? It means if applying that move is appropriate, that is if it doesn’t increase rigidity, fragility or immobility, that is if it doesn’t introduce new smells. Refactoring means applying ex-post OO design principles.
Because of these reasons design is typically decomposed in several classes and responsibilities are fine-graned assigned.
Is it possible to apply TDD following the functional paradigm? I don’t know, my lisp reminiscences are too old. Today I would tend to write OO lisp code, merging together the good of both functional and OO paradigm. I’m quite sure that I would end doing something that is not TDD, probably closely related to, but not exactly TDD for what is commonly meant.