Re: Writing a DAL with TDD
- From: mgsram <mgsram@xxxxxxxxx>
- Date: Mon, 28 Apr 2008 21:03:40 -0700 (PDT)
Whether he is narrating integration problems or not, I think it's utterly
naive to drive a database design from the point of view of the code that
will use the database - which is what you advocated elsewhere. I have been
in the industry for a very long time and have spent a lot of time cleaning
up databases, many times doing complete rewrites, after the initial
developers before me failed to make the database model the real world, and
instead designed the database to model their current application needs.
Applying TDD to the design of a database itself, by definition, means you
are modeling your application's needs and not the real world of the
business. That's a huge mistake that many systems never recover from (and if
the system is important enough, will eventually necessitate a complete
redesign and reimplementation of the database according to a new data model
that captures the real-world of the business).
I fully agree. Re-reading my response, I feel how stupid it was of me
to say
that (Its not impossible, but its not practical either) . Honestly, I
misread
Ben's comment and got carried away.
As I stated in my OP here, I'm absolutely fascinated by TDD and now consider
myself to be a True Believer after having been a sceptic for a long time.
But trying to apply TDD to develop a DAL seems particularly troublesome -
especially if we are to follow the TDD dogma carefully (i.e., have our unit
tests atomic, completely self-contained, etc).
Is DAL not supposed to be a object model layer abstracting a
persistent storage
and exposing a seamless interface for the upper layers? i.e. a layer
where
the output from a SQL / stored procedure is converted to object model
and
vice versa? Is my understanding in error?
Whatever i mentioned in my original post was based on the above. I
think there
is considerable logic involved in translation of Object Model to SQL
( perhaps
you will have a buch of Command builders etc.). This, i think can
certainly
be TDDed following the dogma. I.e. to start from an example of what
the DAL
should appear as to the upper layers and then write the logic for
translation.
Pls correct me if i am fundamentally wrong.
The benefits of TDD seem readily apparent - to me anyway - when applied to
things like developing an application framework or parsing engine, or
designing some new algorithm for a particular business scenario. But when it
comes to designing a DAL... or ASP.NET Web application, where a lot of code
MUST interact with external systems or be dependent on things like ASP.NET
Application state, Session state, or the HTTP request pipeline (which as of
IIS 7 is now fully integrated with the IIS request pipeline), then we're
forced to make our unit tests (if we can even make them true unit tests)
depend on external things like the HTTP request pipeline or an external
database. I know, you'll say that we "just" mock those things...
No. i wont say that. I have had similar experiences ( although I m not
ASP.NET/
IIS developer). I have been able to deal with them by writing simple
wrappers
(and mocking the wrappers if necessary) or having event mocks and
resorting
to behavior testing if my logic is event driven.
That said, I have always found Integration testing to be necessary at
some point
of time and I do have complex Integration tests, sometimes involving
multiple
threads and device simulators. My integration tests often take time to
execute
as i have to collect certain amount of data or run for certain time to
validate
the behavior and therefore, i execute them only once in a while.
Still, they
are way way faster than interfacing with a real device.
I understand mocks. But at what point are we dedicating our development time
to developing complex mocks? Let me see you mock the HTTP Request pipeline
and unit test some code that overrides ASP.NET's Application (Global) .Init
method. If your targeting IIS7 and the request pipeline (say your code
programmatically wires up HTTP modules to handle the various pipeline
events), then your mock would have to emulate IIS7 AND ASP.NET application
startup. That's one enormous mock. At what point does it lose it's value
(especially if you have to make it emulate significant functionality in a
complex integrated system, like the ASP.NET/IIS7 pipeline).
I think if i am testing the wiring up, then it would be integration
testing. I
would not use mocks in such a scenario. Once again, behavior driven
testing
has helped me in such scenarios. In,one of my projects, I had to use
MSMQ and
i did use some of the MSMQ API in testing my message sender class (a
simple
forwarding wrapper on top of MSMQ) to validate that the message was
indeed delivered in
the queue. For all of the other objects, i mocked my wrapper. In fact,
I thought
it gave me more control as intellisense would only show whats
available in the wrapper.
In short, I don't think that TDD is equally valuable for the development of
all types of application components. My OP here was posted so that I could
find out other's opinions on the "TDD-ability" of a DAL.
Given the responses here, and silence from some of this group's more
talented developers (Skeet, Duniho, etc), coupled with the strongest
advocate's (for TDD-ing a dal) promotion of even designing a data model
based on how the application will interact with the database (thereby losing
a bunch of credibity) - I'm concluding that it's (1) difficult or impossible
to go the TDD route in earnest with a DAL, unless (2) we mock the he!! out
of the database and therefore dedicate absolutely huge amounts of effort the
developing mocks. That's not worth it, IMHO.
Sure. I am not one of the talented developers and not a frequent
visitor
to the newsgroup either. As for mocking the DB - no I would not do
that; perhaps
I would use in-memory DB for my integration testing ( on the same
lines of using
a device simulator).
- Sriram
.
- References:
- Writing a DAL with TDD
- From: Cramer
- Re: Writing a DAL with TDD
- From: John B
- Re: Writing a DAL with TDD
- From: Cramer
- Re: Writing a DAL with TDD
- From: Frans Bouma [C# MVP]
- Re: Writing a DAL with TDD
- From: mgsram
- Re: Writing a DAL with TDD
- From: Cramer
- Writing a DAL with TDD
- Prev by Date: Re: Writing a DAL with TDD
- Next by Date: Re: WCF question!
- Previous by thread: Re: Writing a DAL with TDD
- Next by thread: Re: Writing a DAL with TDD
- Index(es):
Relevant Pages
|
