This post originated from an RSS feed registered with .NET Buzz by Udi Dahan. Original Post: Re: MDA or TDD Feed Title: Udi Dahan - The Software Simplist Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple. This blog is about how I do it. Latest .NET Buzz Posts Latest .NET Buzz Posts by Udi Dahan Latest Posts From Udi Dahan - The Software Simplist

Jimmy Nilsson asks the question "MDA or TDD?" and answers "both".

Comparing Model Driven Architecture and Test Driven Development is not unlike comparing the apples and oranges of architecture and development. Development could be said to contain architecture, yet in the TDD sense of the word, development appears to be a disjoint set to architecture.

My short answer to the question is this: Know both ( and more if you can ) and choose the most applicable one for your project.

My (somewhat) long answer is this: From an XP perspective - which sets the context for TDD ( see my previous entry "XP covers TDD's ass" ) - there is always a "system metaphor" which sets the overall direction of the development done, by TDD. The system metaphor can be called architecture, but it really isn't meant to be defined as rigorously.

On MDA, models are a good way to visualize and communicate about the system without getting lost in the details. However, there comes a point ( as a result of the law of dimishing returns ) that making more models just doesn't help very much, and you just gotta get your hands dirty with code to see that your model does what you expect.

So, the long of the short ( or rather the short of the long ) of it is that MDA can be used in concert with TDD.

One final digression, most shops that align themselves around MDA, or are heavily vested in UML will in most cases be leary of TDD if they haven't heard of it before. But, ( and it's a BIG but ), TDD can be sold to these shops as "it's just a coding technique" and "what difference does it make if I write my tests before the code or after, as long as they get written". Yes, this sort of sucks the whole point of TDD out of it, but, hey, whatever works for you.