Is it possible to have TDD without OO?

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.

Period.

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.

Another period.

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.

5 Responses to “Is it possible to have TDD without OO?”

  1. matteo Vaccari Says:

    To say that there is no refactoring unless it’s OO is just like saying it is not possible to improve the design of a program unless it’s OO or unless you make it OO.

    I’m not so sure about this — take a procedural program full of copy-and-pasted code and improve it by factoring out duplicated code in subroutines. It’s certainly an improvement in design; it’s refactoring by the definition of “improve the design while keeping the function”.

    It’s not necessary to continue refactoring until you get to object-orientation; you probably can, but you will start enjoying benefits just by removing duplication.

  2. Zubos Says:

    But refactoring is “restructuring an existing body of code, altering its internal structure without changing its external behavior” and a procedural program you just have external behavior. If you remove a function because it’s duplicated you are removing something that is public!

  3. James Arendt Says:

    Mathematics has the idea of factoring an expression. Factors are cleaner ways of saying the same thing as the original expression. The goal in math is very much the same as what we’re trying to achieve with refactoring — simplicity and elegance. It’s only that math’s factoring predates our refactoring by just tad.😉

    FORTH programmers would apply “factorings” to their own code. Their factorings would break FORTH words (functions) into simpler, more maintainable words. (It appears they took the term straight from mathematics without coining a different terminology.)

    It’s only until recently (starting in the 90s) that refactoring has become the term used for doing the same things to the structure of programs; usually OO programs.

    I would argue that makes refactoring not particularly suited to OOP, but a practice that should be employed by programmers of all styles (procedural, functional, OO).

  4. theboxx Says:

    Folks,

    I agree with you: in theory what any of you have said is right; but in practice refactoring is based on good ol’ design principles + readability. Because there is no refactoring without a definition of bad design and I know the OO definition of bad design. All the bad smells may be brought back to bad OO design. And there are refactoring moves (like “Replace conditional with polymorphism” for example) that are clearly rooted in OO paradigm. I mean, lots of them, if not all, have sense only with reference to the OO paradigm.

    To say the least, if your horizon is not shaped by OO concepts you need a clean and precise and objective way to define what bad design means.

    I’d like to have more feedback from people coming from the functional programming paradigm though.

    So, in theory you are right and I entirely agree with you. Pragmatically, I think that while facing TDD one needs to: 1) focus especially to OO design principles and 2) learn how to apply them afterwards. This is particularly true for newbies.

  5. alaa Says:

    that cool

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: