I've finally gotton board with TDD (test driven development) and wow is it
effective! I went from sceptic to True Believer with my first effort.
My question: According to the various books and articles I have read about
TDD, a good unit test does not rely on the database or other such
external/environmental conditions. More generally, a good unit test is
atomic and makes as few assumptions about its runtime environment as
possible. But what about developing unit tests for a DAL - whose purpose in
life is to interact with a database?
Your thoughts and opinions are appreciated.
30  2644 
On Apr 23, 11:16 am, "Cramer" <A...@B.comwrote:
I've finally gotton board with TDD (test driven development) and wow is it
effective! I went from sceptic to True Believer with my first effort.
My question: According to the various books and articles I have read about
TDD, a good unit test does not rely on the database or other such
external/environmental conditions. More generally, a good unit test is
atomic and makes as few assumptions about its runtime environment as
possible. But what about developing unit tests for a DAL - whose purpose in
life is to interact with a database?
Your thoughts and opinions are appreciated.
I would test the behavior in the DAL. I m not very well versed with DB
programming
but, as far as i know DAL abstracts a bunch of SQL statements or calls
to
stored procedures in the DB.
So I would test for setting up the adapter object that actually
tunnels the call to the DB.
The rationale is that if you have validated the behavior that sets up
the adapter object,
then it will work correctly when you connect a actual DB.
If the Adapter object cannot be mocked direclty, then I would write a
simple wrapper around
that, that mocks the adapter.
"Cramer" <A@B.comwrote in message
news:eZ**************@TK2MSFTNGP03.phx.gbl...
I've finally gotton board with TDD (test driven development) and wow is it
effective! I went from sceptic to True Believer with my first effort.
My question: According to the various books and articles I have read about
TDD, a good unit test does not rely on the database or other such
external/environmental conditions. More generally, a good unit test is
atomic and makes as few assumptions about its runtime environment as
possible. But what about developing unit tests for a DAL - whose purpose
in life is to interact with a database?
Your thoughts and opinions are appreciated.
You could do the unit test of the DAL through the interfaces of the Business
layer that interacts with the DAL.
This link has shows about TDD and unit testing of a TDD solution. http://www.polymorphicpodcast.com/
There is also this which can show you how to develop your solutions, and how
you can test through the interface. You should be able to develop a test
harness for the interface or use something line Nunit.
MODEL-VIEW-PRESENTER http://www.polymorphicpodcast.com/
click 'Shows'
click 'Design Patterns Bootcamp: Model View * Patterns*
view parts 1-5
Cramer wrote:
I've finally gotton board with TDD (test driven development) and wow
is it effective! I went from sceptic to True Believer with my first
effort.
My question: According to the various books and articles I have read
about TDD, a good unit test does not rely on the database or other
such external/environmental conditions. More generally, a good unit
test is atomic and makes as few assumptions about its runtime
environment as possible. But what about developing unit tests for a
DAL - whose purpose in life is to interact with a database?
The unit test needs to create a new database in a known state, open it using
the DAL under test, verify the results, clean up the database.
>
Your thoughts and opinions are appreciated.
On Apr 24, 11:52 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
Cramer wrote:
I've finally gotton board with TDD (test driven development) and wow
is it effective! I went from sceptic to True Believer with my first
effort.
My question: According to the various books and articles I have read
about TDD, a good unit test does not rely on the database or other
such external/environmental conditions. More generally, a good unit
test is atomic and makes as few assumptions about its runtime
environment as possible. But what about developing unit tests for a
DAL - whose purpose in life is to interact with a database?
The unit test needs to create a new database in a known state, open it using
the DAL under test, verify the results, clean up the database.
Your thoughts and opinions are appreciated.
Ben,
Then it wont be a unit test in the TDD sense. In fact i would argue
that its not unit test at all and more of Integration testing. The
point is your tests would be "lazy" and would not help you drive the
design of DAL which is what the goal is.
mgsram wrote:
On Apr 24, 11:52 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
>Cramer wrote:
>>I've finally gotton board with TDD (test driven development) and wow
is it effective! I went from sceptic to True Believer with my first
effort.
My question: According to the various books and articles I have read
about TDD, a good unit test does not rely on the database or other
such external/environmental conditions. More generally, a good unit
test is atomic and makes as few assumptions about its runtime
environment as possible. But what about developing unit tests for a
DAL - whose purpose in life is to interact with a database?
The unit test needs to create a new database in a known state, open
it using the DAL under test, verify the results, clean up the
database.
>>Your thoughts and opinions are appreciated.
Ben,
Then it wont be a unit test in the TDD sense. In fact i would argue
that its not unit test at all and more of Integration testing. The
point is your tests would be "lazy" and would not help you drive the
design of DAL which is what the goal is.
Well... ok. This might no be considered a unit test anymore, it is quite
heavy.
But there's no reason that you couldn't still develop the test before the
code. You could even use the test to drive database layout (this might not
be very effective at normalization though).
On Apr 24, 6:07 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
mgsram wrote:
On Apr 24, 11:52 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
Cramer wrote:
I've finally gotton board with TDD (test driven development) and wow
is it effective! I went from sceptic to True Believer with my first
effort.
My question: According to the various books and articles I have read
about TDD, a good unit test does not rely on the database or other
such external/environmental conditions. More generally, a good unit
test is atomic and makes as few assumptions about its runtime
environment as possible. But what about developing unit tests for a
DAL - whose purpose in life is to interact with a database?
The unit test needs to create a new database in a known state, open
it using the DAL under test, verify the results, clean up the
database.
>Your thoughts and opinions are appreciated.
Ben,
Then it wont be a unit test in the TDD sense. In fact i would argue
that its not unit test at all and more of Integration testing. The
point is your tests would be "lazy" and would not help you drive the
design of DAL which is what the goal is.
Well... ok. This might no be considered a unit test anymore, it is quite
heavy.
But there's no reason that you couldn't still develop the test before the
code. You could even use the test to drive database layout (this might not
be very effective at normalization though).
Absolutely,
I agree. In fact thats how i would even design my Database tables.
Cramer wrote:
I've finally gotton board with TDD (test driven development) and wow is it
effective! I went from sceptic to True Believer with my first effort.
My question: According to the various books and articles I have read about
TDD, a good unit test does not rely on the database or other such
external/environmental conditions. More generally, a good unit test is
atomic and makes as few assumptions about its runtime environment as
possible. But what about developing unit tests for a DAL - whose purpose in
life is to interact with a database?
Your thoughts and opinions are appreciated.
Similar to what Ben said,
We used to have a "test" database (or one of each, mssql, mysql, oracle)
that each time would be cleaned out and then repopulated by each test.
It might not be very scaleable but worked well for what we were doing at
the time which encompassed 500+ tests running in around 20 seconds.
JB
Cramer wrote:
>I've finally gotton board with TDD (test driven development) and wow is
it effective! I went from sceptic to True Believer with my first effort.
My question: According to the various books and articles I have read
about TDD, a good unit test does not rely on the database or other such
external/environmental conditions. More generally, a good unit test is
atomic and makes as few assumptions about its runtime environment as
possible. But what about developing unit tests for a DAL - whose purpose
in life is to interact with a database?
Your thoughts and opinions are appreciated.
Similar to what Ben said,
We used to have a "test" database (or one of each, mssql, mysql, oracle)
that each time would be cleaned out and then repopulated by each test.
It might not be very scaleable but worked well for what we were doing at
the time which encompassed 500+ tests running in around 20 seconds.
Thank you John,
Along the lines of what you did, I have heard unit tests (against a DB)
doing something like this: (1) open a transaction in the test fixture setup;
(2) run the tests; (3) roll back the transaction in the test fixture
teardown.
-Cramer
mgsram wrote:
On Apr 24, 11:52 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
Cramer wrote:
I've finally gotton board with TDD (test driven development) and
wow is it effective! I went from sceptic to True Believer with my
first effort.
My question: According to the various books and articles I have
read about TDD, a good unit test does not rely on the database or
other such external/environmental conditions. More generally, a
good unit test is atomic and makes as few assumptions about its
runtime environment as possible. But what about developing unit
tests for a DAL - whose purpose in life is to interact with a
database?
The unit test needs to create a new database in a known state, open
it using the DAL under test, verify the results, clean up the
database.
Your thoughts and opinions are appreciated.
Ben,
Then it wont be a unit test in the TDD sense. In fact i would argue
that its not unit test at all and more of Integration testing. The
point is your tests would be "lazy" and would not help you drive the
design of DAL which is what the goal is.
'Designing' a dal using TDD is silly anyway, as a DAL has an
unlimited amount of usage scenario's so you can't design it by starting
with tests, you can only design it in a more generic way and use
unittests for integration tests and automated checks for expected edge
cases in the generic design.
Anyone who thinks s/he can design a DAL using TDD has never even made
an attempt to do so.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
mgsram wrote:
On Apr 24, 6:07 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
mgsram wrote:
On Apr 24, 11:52 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospam>
wrote:
>Cramer wrote:
>>I've finally gotton board with TDD (test driven development)
and wow >>is it effective! I went from sceptic to True Believer
with my first >>effort.
>>My question: According to the various books and articles I have
read >>about TDD, a good unit test does not rely on the database
or other >>such external/environmental conditions. More
generally, a good unit >>test is atomic and makes as few
assumptions about its runtime >>environment as possible. But what
about developing unit tests for a >>DAL - whose purpose in life
is to interact with a database?
>The unit test needs to create a new database in a known state,
open >it using the DAL under test, verify the results, clean up
the >database.
>>Your thoughts and opinions are appreciated.
Ben,
Then it wont be a unit test in the TDD sense. In fact i would
argue that its not unit test at all and more of Integration
testing. The point is your tests would be "lazy" and would not
help you drive the design of DAL which is what the goal is.
Well... ok. This might no be considered a unit test anymore, it is
quite heavy.
But there's no reason that you couldn't still develop the test
before the code. You could even use the test to drive database
layout (this might not be very effective at normalization though).
Absolutely,
I agree. In fact thats how i would even design my Database tables.
err.... how can an abstract entity definition be based on a test? A
test drives API design, not which attributes belong to which entity
definition, which supertype it inherits from nor which entity
definitions it has relationships with over which attributes nor which
relationships are objectified and form entities themselves
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
<snip>
I would encourage posting this on the yahoo groups for TDD. You will
certainly get better answers. IMO, once again what Frank is narrating
is Integration problems
-Sriram
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).
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).
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...
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).
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.
-Cramer
On Apr 25, 12:51 pm, "Cramer" <A...@B.comwrote:
<snip>
I would encourage posting this on the yahoo groups for TDD. You will
certainly get better answers. IMO, once again what Frank is narrating
is Integration problems
-Sriram
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).
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).
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...
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).
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.
-Cramer
Cramer,
Do you have a problem statement that I can use to verify what you are
saying? Of course this is for my benefit and I will be glad to share
my findings with you.
-Sriram
Cramer <A@B.comwrote:
<snip>
Given the responses here, and silence from some of this group's more
talented developers (Skeet, Duniho, etc)
In general, don't draw any conclusions from me being silent on a topic.
I don't have as much time for checking the newsgroup as I used to, and
to be honest I hadn't even seen this thread until just now.
I have friends who certainly *have* mocked out their data access. I've
found it too difficult to do in the past, but they're more skillful at
TDD than I am.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
Mr. Arnold wrote:
"Cramer" <A@B.comwrote in message
news:eZ**************@TK2MSFTNGP03.phx.gbl...
>I've finally gotton board with TDD (test driven development) and wow
is it effective! I went from sceptic to True Believer with my first
effort.
My question: According to the various books and articles I have read
about TDD, a good unit test does not rely on the database or other
such external/environmental conditions. More generally, a good unit
test is atomic and makes as few assumptions about its runtime
environment as possible. But what about developing unit tests for a
DAL - whose purpose in life is to interact with a database?
Your thoughts and opinions are appreciated.
You could do the unit test of the DAL through the interfaces of the
Business layer that interacts with the DAL.
I don't think the BLL developers will appreciate having
to guess whether their unit test failures are due to their
bugs or due to bugs in the DAL somebody else delivered
without unit testing.
Arne
Cramer wrote:
I've finally gotton board with TDD (test driven development) and wow is it
effective! I went from sceptic to True Believer with my first effort.
My question: According to the various books and articles I have read about
TDD, a good unit test does not rely on the database or other such
external/environmental conditions. More generally, a good unit test is
atomic and makes as few assumptions about its runtime environment as
possible. But what about developing unit tests for a DAL - whose purpose in
life is to interact with a database?
If you were to be very strict about unit test then you need a mock
ADO.NET provider.
But I would suggest being a bit pragmatic and test DAL against a
real database.
Arne
Frans Bouma [C# MVP] wrote:
'Designing' a dal using TDD is silly anyway, as a DAL has an
unlimited amount of usage scenario's so you can't design it by starting
with tests, you can only design it in a more generic way and use
unittests for integration tests and automated checks for expected edge
cases in the generic design.
I don't think DAL is more generic than any other layer except
presentation layers. Other layers are supposed to be reusable too.
And the difference between "TDD for DAL" and "unit tests for
generic design of DAL" sound more as a difference in terminology
than a real difference in process.
Arne
Cramer wrote:
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).
If the scope for the DL and DAL is to be reusable, then TDD will also
work for them.
I know that TDD purists will argue KISS and YAGNI, but most development
methodologies work best with a bit of pragmatism.
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).
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...
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).
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.
It is not surprising that a methodology need to be customized to fit
with a given development context.
Arne
Arne Vajhøj wrote:
Frans Bouma [C# MVP] wrote:
> 'Designing' a dal using TDD is silly anyway, as a DAL has an
unlimited amount of usage scenario's so you can't design it by starting
with tests, you can only design it in a more generic way and use
unittests for integration tests and automated checks for expected edge
cases in the generic design.
I don't think DAL is more generic than any other layer except
presentation layers. Other layers are supposed to be reusable too.
That's not an explanation how to solve the 'unlimited usage' problem
when it comes to designing a DAL: how are you going to be sure your
tests cover all possible usages, so you know your DAL is correct?
And the difference between "TDD for DAL" and "unit tests for
generic design of DAL" sound more as a difference in terminology
than a real difference in process.
isn't TDD for DAL starting with the test, mocking the DAL out, then
requiring you to write the real code instead of using the mocks, while
the automated unittests for testing edge cases is more for easing the
proving process of the design?
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Frans Bouma [C# MVP] wrote:
Arne Vajhøj wrote:
>Frans Bouma [C# MVP] wrote:
>> 'Designing' a dal using TDD is silly anyway, as a DAL has an
unlimited amount of usage scenario's so you can't design it by starting
with tests, you can only design it in a more generic way and use
unittests for integration tests and automated checks for expected edge
cases in the generic design.
I don't think DAL is more generic than any other layer except
presentation layers. Other layers are supposed to be reusable too.
That's not an explanation how to solve the 'unlimited usage' problem
when it comes to designing a DAL: how are you going to be sure your
tests cover all possible usages, so you know your DAL is correct?
That is not possible.
My point is that it is also impossible for other layers.
>And the difference between "TDD for DAL" and "unit tests for
generic design of DAL" sound more as a difference in terminology
than a real difference in process.
isn't TDD for DAL starting with the test, mocking the DAL out, then
requiring you to write the real code instead of using the mocks, while
the automated unittests for testing edge cases is more for easing the
proving process of the design?
You can not prove code to be correct with unit tests.
And even "traditional non-TDD unit tests" approach would prefer
to write the unit tests before.
There should be some difference in the role of the tests in the
design process.
But I do not see it as black and white - more like 10 different
shades of gray.
Arne
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).
Here's the difference between a mock and a test environment. You can quite
easily run real IIS or database engine or whatever, but feed in controlled
data.
Note that I didn't say you'd come up with the best solution using TDD to
drive database design. I simply said you can fill a database with sample
data and use that to drive TDD of your interface code, and that it was
theoretically also possible to apply TDD to the table layout itself.
>
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.
It sounds as if you made up your mind already to not test the DAL, and came
looking for affirmation (to strengthen your case with a manager perhaps).
If so, you approached the newsgroup entirely wrong and wasted everyone's
time.
>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).
Here's the difference between a mock and a test environment. You can
quite easily run real IIS or database engine or whatever, but feed in
controlled data.
Note that I didn't say you'd come up with the best solution using TDD to
drive database design.
I know *you* didn't, but the person posting as "mgsram" did promote the
idea.
>I simply said you can fill a database with sample data and use that to
drive TDD of your interface code,
You and others mentioned that, and I raised no concerns about using test
data - ever... gotta have test data.
and that it was theoretically also possible to apply TDD to the table
layout itself.
Just because it's theoretically possible doesn't mean that it's a good idea
(to design a relational database based almost exclusively on how it will be
used, which is what TDD would do).
>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.
It sounds as if you made up your mind already to not test the DAL,
You are only partially right - I did make up my mind, but only after getting
a bunch of responses to my OP here. At the time I posted the OP, I thought
that maybe I was missing something about TDD if I was having a difficult
time applying it to my DAL. I'm working on a green field project and just
got on board with the idea of TDD - as I stated - and being new to TDD
figured the group might provide some pointers to help me get "unstuck." What
I got was an explanation of *why* it's difficult (perhaps prohibitively
expensive anyway), to develop a DAL via TDD.
The responses that stated that I could apply TDD to the DAL, and even use
TDD to design the relational database immediately lost all credibility. I'm
new to TDD, but not to data modeling and client/server business application
development. Anybody promoting the idea of applying TDD to designing a
database, IMHO, is dangerous to their employer. That's not meant as an
attack on anybody here personally. It's just a fact. I'd even say that it's
*probably never* a good idea to design a relational database based
exclusively or even mostly on how the data will be programmatically
accessed - which is what TDD would inherently do.
and came looking for affirmation (to strengthen your case with a manager
perhaps).
I *am* the manager. Geeze! I'm actually the technical lead and I have
complete control over this green field project - not only the technical
implementation, but also on the development process. The people I work for
have absolutely zero say in how development proceeds. They just want the
final product. They will never hear about "TDD" much less be able to tell me
yes or no about employing it. And, I do see TDD as very powerful and
currently *require* it's use on this project... just not on *every* aspect
of this project - and probably never on a DAL, or HTTP pipeline
configuration code, and other such things were mocking it would be
prohibitively expensive.
BTW: I'm writing this not to defend anything - but simply to point out how
wrong you are about this. It's beyond me why you seem so personally
offended.
If so, you approached the newsgroup entirely wrong and wasted everyone's
time.
Even if you were right, it is not a wast of everyone's time to have a lively
discussion in which beliefs are challenged. As a result of the challenge
you'll either (1) change your beliefs for the better; or (2) affirm your
beliefs. You can't go wrong either way.
-Cramer
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 this is incorrect.
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).
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
Ben Voigt [C++ MVP] wrote:
>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.
It sounds as if you made up your mind already to not test the DAL, and came
looking for affirmation (to strengthen your case with a manager perhaps).
Not using TDD to create the DAL doesn't mean 'not testing the DAL'.
There are numerous ways to make sure your software works. As a DAL is a
general purpose layer which has unlimited # of usage scenario's, it's
impossible to test it with just that: a set of usage scenarios. You
therefore need different ways to test if the DAL is correct.
I think that was the point Cramer was trying to make.
If so, you approached the newsgroup entirely wrong and wasted everyone's
time.
I think the thread was very useful, as you seem to forget that most
people visiting a newsgroup (through an NNTP reader or most likely
through google groups) aren't posting at all but just lurking.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
mgsram wrote:
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?
Not in error but I would say not complete.
The DAL is supposed to convert between the database and objects
of data classes. The data classes can be part of the DAL or be in a
separate layer.
Arne
Cramer wrote:
Just because it's theoretically possible doesn't mean that it's a good idea
(to design a relational database based almost exclusively on how it will be
used, which is what TDD would do).
It does not make sense to design a database after how it will not
be used.
Obviously a database should be designed after how it will be used.
The difference is only in the application and time scope. This app
now versus all apps the next 25 years.
The responses that stated that I could apply TDD to the DAL, and even use
TDD to design the relational database immediately lost all credibility. I'm
new to TDD, but not to data modeling and client/server business application
development. Anybody promoting the idea of applying TDD to designing a
database, IMHO, is dangerous to their employer. That's not meant as an
attack on anybody here personally. It's just a fact.
The only fact of that is that you have a very narrow definition
of TDD and seem incapable of understanding it when it is explained to
you.
BTW: I'm writing this not to defend anything - but simply to point out how
wrong you are about this.
Wise men listen more than they talk.
Arne
Cramer wrote:
Given all of the above, it should be pretty clear that "designing a
relational database via TDD" why elsewhere in this thread I pointed out that
trying to design a database via TDD is irresponsible. The specific reason it
is irresponsible and even dangerous is that it would lead to a relational
database design that literally models programmatic access as opposed to a
subset of the real-world business model.
I think you have missed the point in having a DAL.
--(OO I/F)--DAL--(R I/F)--DB
The OO I/F and R I/F are completely decoupled and therefore
the methodology used to design the OO I/F will not have any
impact on the R I/F.
BTW: This is all why MS Access is such a terrible product (beyond my
opinion) and IS departments in many big enterprises outright deny it's use
throughout the enterprise. MS Access lets non technical users bind the UI
directly to the underlying tables. This is the most extreme form of
"designing a database based on how the client application will use it."
This is because there are no DAL at all in that case.
Arne
REsponses inline:
"Arne Vajhøj" wrote
Cramer wrote:
>Just because it's theoretically possible doesn't mean that it's a good
idea (to design a relational database based almost exclusively on how it
will be used, which is what TDD would do).
It does not make sense to design a database after how it will not
be used.
Obviously a database should be designed after how it will be used.
No - not at all. To the contrary, a database should be designed to model
the "real-world" entities and attributes of the business. The
program/software, DAL and all, then needs to figure out how to interact with
that real-world representation of the business model in the database. The
scope, itself, of what gets included in the data model and subsequently
built in the database, is determined by how the application will be used -
or more accurately the role the application will play in the business.
You are therefore correct to say that it does not make sense to design a
database after how it will not be used. That makes no sense at all and it's
amazing that you would conclude that that is what I was saying after stating
in multiple places in this thread that a database should model the real
world of the business (or a subset thereof).
What I'm saying is "not a good idea" is to build a database based on how it
will be used *by the client software* including the DAL. It's in fact a bad
idea.
Case in point: Say you need to provide a report that lists customers and
their phone numbers. TDD would have us build a single table, Customers, with
three columns: FirstName, LastName, and PhoneNumber. Then as requirements
evolve, we'd need to have two phone numbers. So you'd add a second phone
number to the Customers table. Your reports work, you go from "red to green"
in a matter of minutes, and in the TDD world all is well. But your data
model is suddenly violating 2nd Normal Form (if you don't know why that's a
problem, then you're in trouble... well, actually your employer is, but I
digress). Then you need a 3rd phone number and add 3rd column... you see how
this is going. Well, according to the TDD way of doing things (which, btw, I
really; like - just not for data modeling), we find that we need to refactor
("mercilessly, in fact). Now is when we start seeing why TDD is really; a
problemmatic way to go with designing a database. Because we didn't model
the real-world of the business up front, we're now breaking out our phone
numbers into a separate PhoneNumbers (or ContactNumbers) table. When we do
this, we break all of our queries that were based on one table being in
existance, and probably break all of the code that consumed the result set
of those queries. Yes, we *can* refactor this way, but it's probably the
most costly in terms of development time and effort. Now, contrast that TDD
approach to developing a data model with the approach that says we should
model the real world of the business. With that approach, we would meet with
subject matter experts early and have them identify the ways *they* need to
interact with their data, what data points are of significance to them
(within the mission of this particualar database). Before we write one line
of code or build one table or unit test, we know that we would need to track
multiple phone/contact numbers per customer - and therefore, starting on Day
One, we'd build separate Customers and ContactNumbers tables. No need to
refactor (which is TDD's calling card). From Day One, we have this database
normalized through at least 3rd Normal Form.
In short, yes, we *could* use TDD to design a datababase, but the
refactoring part is super expensive when we have to refactor database
structures... reason being is that when we break out tables (or combind
them) we break the queries that worked with the original table design. This
ripples directly to any stored procedures or application code that worked
with those queries.
>The responses that stated that I could apply TDD to the DAL, and even use
TDD to design the relational database immediately lost all credibility.
I'm new to TDD, but not to data modeling and client/server business
application development. Anybody promoting the idea of applying TDD to
designing a database, IMHO, is dangerous to their employer. That's not
meant as an attack on anybody here personally. It's just a fact.
The only fact of that is that you have a very narrow definition
of TDD and seem incapable of understanding it when it is explained to you.
Just because I don't agree with something doesn't mean that I'm not
understanding what is being said.
If you believe that a DAL *should* be developed with TDD (and not simply
that it's theoretically possible), please provide some explanation (which
means more than making statements). You can say that pigs fly. But until you
provide some compelling logic, then very few people are going to agree with
you.
If it's so incredibly obvious - as you seem to think - then you should be
able to provide an example... just like I did above (with the Customers and
Contacts scenario). Come on - if it's so incredibly simple, then you should
be able to do this without any hesitation or problem. Just one simple
example of how it's good or better to develop a data model via TDD than it
would be to develop it according to the real-world business model.
>BTW: I'm writing this not to defend anything - but simply to point out
how wrong you are about this.
Wise men listen more than they talk.
Agreed - and did you take a moment to consider what I was referring to when
I wrote that? Or were you just talking before you listened?
On May 5, 12:32 am, "Cramer" <A...@B.comwrote:
REsponses inline:
"Arne Vajhøj" wrote
Cramer wrote:
Just because it's theoretically possible doesn't mean that it's a good
idea (to design a relational database based almost exclusively on how it
will be used, which is what TDD would do).
It does not make sense to design a database after how it will not
be used.
Obviously a database should be designed after how it will be used.
No - not at all. To the contrary, a database should be designed to model
the "real-world" entities and attributes of the business. The
program/software, DAL and all, then needs to figure out how to interact with
that real-world representation of the business model in the database. The
scope, itself, of what gets included in the data model and subsequently
built in the database, is determined by how the application will be used -
or more accurately the role the application will play in the business.
You are therefore correct to say that it does not make sense to design a
database after how it will not be used. That makes no sense at all and it's
amazing that you would conclude that that is what I was saying after stating
in multiple places in this thread that a database should model the real
world of the business (or a subset thereof).
What I'm saying is "not a good idea" is to build a database based on how it
will be used *by the client software* including the DAL. It's in fact a bad
idea.
Absolutely. However when you set out with TDD, the objective is not to
satisfy the *client software*. It is to satisfy the user requirements.
DAL or no DAL, the user cares less. Don't get me wrong here. I m not
saying DAL is not required. All i want to say is you need to design
your Database as well ad DAL in the best possible manner that
completely satisfies user requirements - no less, no more.
Case in point: Say you need to provide a report that lists customers and
their phone numbers. TDD would have us build a single table, Customers, with
three columns: FirstName, LastName, and PhoneNumber. Then as requirements
evolve, we'd need to have two phone numbers. So you'd add a second phone
number to the Customers table. Your reports work, you go from "red to green"
in a matter of minutes, and in the TDD world all is well. But your data
model is suddenly violating 2nd Normal Form (if you don't know why that's a
problem, then you're in trouble... well, actually your employer is, but I
digress). Then you need a 3rd phone number and add 3rd column... you see how
this is going. Well, according to the TDD way of doing things (which, btw,I
really; like - just not for data modeling), we find that we need to refactor
("mercilessly, in fact). Now is when we start seeing why TDD is really; a
problemmatic way to go with designing a database. Because we didn't model
the real-world of the business up front, we're now breaking out our phone
numbers into a separate PhoneNumbers (or ContactNumbers) table. When we do
this, we break all of our queries that were based on one table being in
existance, and probably break all of the code that consumed the result set
of those queries. Yes, we *can* refactor this way, but it's probably the
most costly in terms of development time and effort. Now, contrast that TDD
approach to developing a data model with the approach that says we should
model the real world of the business. With that approach, we would meet with
subject matter experts early and have them identify the ways *they* need to
interact with their data, what data points are of significance to them
(within the mission of this particualar database). Before we write one line
of code or build one table or unit test, we know that we would need to track
multiple phone/contact numbers per customer - and therefore, starting on Day
One, we'd build separate Customers and ContactNumbers tables. No need to
refactor (which is TDD's calling card). From Day One, we have this database
normalized through at least 3rd Normal Form.
What you have narrated above is a possible situation that you could be
in when you have not understood the requirements clearly. It has
nothing to do with TDD. TDD does not prescribe following the above
steps, if you know from the beginning that you need to have 3 phone
numbers. The "Subject Matter Experts" (SME) should be your customers
and they should be able to tell you what they need. If the SME
initially required only one phone number, I see nothing wrong in
having a single phone number column and moving ahead; and yes, if they
come back later and ask me to adding more phone numbers, i would
refactor as necessary ( Note: if none of the 3 phone numbers are
optional, then there is nothing wrong in having 3 columns).
>
In short, yes, we *could* use TDD to design a datababase, but the
refactoring part is super expensive when we have to refactor database
structures... reason being is that when we break out tables (or combind
them) we break the queries that worked with the original table design. This
ripples directly to any stored procedures or application code that worked
with those queries.
Yes, the refactored changes does ripple into stored procedures,
application code etc. But then your tests should go RED and to get to
GREEN you will have to fix them. This way atleast you are saved from
introducing breaking changes in the software.
Moreover, can you gaurantee that once your DB has been designed, you
will never have to change the table structure ever ? I suppose not.
When you design an application for users and when users use the
system, they would certainly feedback and some of their feedback can
drive changes that may involve DB layer as well. How would you deal
with these changes, if you did not have any tests to cover?
>
The responses that stated that I could apply TDD to the DAL, and even use
TDD to design the relational database immediately lost all credibility.
I'm new to TDD, but not to data modeling and client/server business
application development. Anybody promoting the idea of applying TDD to
designing a database, IMHO, is dangerous to their employer. That's not
meant as an attack on anybody here personally. It's just a fact.
The only fact of that is that you have a very narrow definition
of TDD and seem incapable of understanding it when it is explained to you.
Just because I don't agree with something doesn't mean that I'm not
understanding what is being said.
If you believe that a DAL *should* be developed with TDD (and not simply
that it's theoretically possible), please provide some explanation (which
means more than making statements). You can say that pigs fly. But until you
provide some compelling logic, then very few people are going to agree with
you.
If it's so incredibly obvious - as you seem to think - then you should be
able to provide an example... just like I did above (with the Customers and
Contacts scenario). Come on - if it's so incredibly simple, then you should
be able to do this without any hesitation or problem. Just one simple
example of how it's good or better to develop a data model via TDD than it
would be to develop it according to the real-world business model.
I suggested doing a POC before. I m still open to it. Give me a
problem statement and lets change the requirements and see how it
fares. You have nothing to loose and perhaps there is something to
gain for all of us here.
BTW: I'm writing this not to defend anything - but simply to point out
how wrong you are about this.
Wise men listen more than they talk.
Agreed - and did you take a moment to consider what I was referring to when
I wrote that? Or were you just talking before you listened?
Cramer wrote:
"Arne Vajhøj" wrote
>Cramer wrote:
>>Just because it's theoretically possible doesn't mean that it's a good
idea (to design a relational database based almost exclusively on how it
will be used, which is what TDD would do).
It does not make sense to design a database after how it will not
be used.
Obviously a database should be designed after how it will be used.
No - not at all. To the contrary, a database should be designed to model
the "real-world" entities and attributes of the business. The
program/software, DAL and all, then needs to figure out how to interact with
that real-world representation of the business model in the database. The
scope, itself, of what gets included in the data model and subsequently
built in the database, is determined by how the application will be used -
or more accurately the role the application will play in the business.
You are therefore correct to say that it does not make sense to design a
database after how it will not be used. That makes no sense at all and it's
amazing that you would conclude that that is what I was saying after stating
in multiple places in this thread that a database should model the real
world of the business (or a subset thereof).
What I'm saying is "not a good idea" is to build a database based on how it
will be used *by the client software* including the DAL. It's in fact a bad
idea.
Both databases and object model should be designed to model the real
world. Database is not special here.
It is impossible to model all aspect of the real world. You have to only
model the relevant parts.
Relevant parts are those that will be used.
Used means "what" the client apps will need.
I agree that "how" the client apps need them is a bad idea.
Case in point: Say you need to provide a report that lists customers and
their phone numbers. TDD would have us build a single table, Customers, with
three columns: FirstName, LastName, and PhoneNumber. Then as requirements
evolve, we'd need to have two phone numbers. So you'd add a second phone
number to the Customers table. Your reports work, you go from "red to green"
in a matter of minutes, and in the TDD world all is well. But your data
model is suddenly violating 2nd Normal Form (if you don't know why that's a
problem, then you're in trouble... well, actually your employer is, but I
digress). Then you need a 3rd phone number and add 3rd column... you see how
this is going. Well, according to the TDD way of doing things (which, btw, I
really; like - just not for data modeling), we find that we need to refactor
("mercilessly, in fact). Now is when we start seeing why TDD is really; a
problemmatic way to go with designing a database. Because we didn't model
the real-world of the business up front, we're now breaking out our phone
numbers into a separate PhoneNumbers (or ContactNumbers) table. When we do
this, we break all of our queries that were based on one table being in
existance, and probably break all of the code that consumed the result set
of those queries. Yes, we *can* refactor this way, but it's probably the
most costly in terms of development time and effort. Now, contrast that TDD
approach to developing a data model with the approach that says we should
model the real world of the business. With that approach, we would meet with
subject matter experts early and have them identify the ways *they* need to
interact with their data, what data points are of significance to them
(within the mission of this particualar database). Before we write one line
of code or build one table or unit test, we know that we would need to track
multiple phone/contact numbers per customer - and therefore, starting on Day
One, we'd build separate Customers and ContactNumbers tables. No need to
refactor (which is TDD's calling card). From Day One, we have this database
normalized through at least 3rd Normal Form.
You are using a straw man argument.
Noone will use TDD to design a database that way.
In short, yes, we *could* use TDD to design a datababase, but the
refactoring part is super expensive when we have to refactor database
structures... reason being is that when we break out tables (or combind
them) we break the queries that worked with the original table design. This
ripples directly to any stored procedures or application code that worked
with those queries.
Not really any different from object model. Making incompatible changes
also break code.
>>The responses that stated that I could apply TDD to the DAL, and even use
TDD to design the relational database immediately lost all credibility.
I'm new to TDD, but not to data modeling and client/server business
application development. Anybody promoting the idea of applying TDD to
designing a database, IMHO, is dangerous to their employer. That's not
meant as an attack on anybody here personally. It's just a fact.
The only fact of that is that you have a very narrow definition
of TDD and seem incapable of understanding it when it is explained to you.
Just because I don't agree with something doesn't mean that I'm not
understanding what is being said.
You have been told plenty of times that your definition of TDD is too
narrow. But you just keep arguing based on your definition. If you
understand us, then you being very rude.
If you believe that a DAL *should* be developed with TDD (and not simply
that it's theoretically possible), please provide some explanation (which
means more than making statements). You can say that pigs fly. But until you
provide some compelling logic, then very few people are going to agree with
you.
If it's so incredibly obvious - as you seem to think - then you should be
able to provide an example... just like I did above (with the Customers and
Contacts scenario). Come on - if it's so incredibly simple, then you should
be able to do this without any hesitation or problem. Just one simple
example of how it's good or better to develop a data model via TDD than it
would be to develop it according to the real-world business model.
1) You write the tests.
I would say:
- good insert in customers
- good insert in contacts
- join with one contact for customer
- join with multiple contacts per customer
- insert for default value
- insert for range
- insert for constraints
2) You implement the database structure.
3) You run tests and verify that all tests pass. If not you fix
the structure.
Pretty simple.
Arne This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Joseph |
last post by:
Hi
I'm writing a commercial program which must be reliable. It has to do
some basic reading and writing to and from files on the hard disk,
and also to a floppy.
I have foreseen a potential...
|
by: Sebastian Kemi |
last post by:
How should a write a class to a file?
Would this example work:
object *myobject = 0;
tfile.write(reinterpret_cast<char *>(myobject), sizeof(*object));
/ sebek
|
by: ishekar |
last post by:
Hi,
I have an application where i want to write data to a file, the data is
being sent from an external source. I know the total size of the data and
then i retrieve the data in small segments...
|
by: Daniel |
last post by:
System.IO.StreamWriter Close or Flush method to shut down the computer in
such a way that just part of the file is written? or an empty file is
written? Also if the Close or Flush is to a...
|
by: Jeong-Gun Lee |
last post by:
I'm writing a code of writing a value to a specific memory address.
=================================================================
#include <stdio.h>
int main()
{
long air;
long...
|
by: Xah Lee |
last post by:
i had the pleasure to read the PHP's manual today.
http://www.php.net/manual/en/
although Pretty Home Page is another criminal hack of the unix lineage,
but if we are here to judge the quality...
|
by: Claudio Grondi |
last post by:
I have a 250 Gbyte file (occupies the whole hard drive space) and want
to change only eight bytes in this file at a given offset of appr. 200
Gbyte (all other data in that file should remain...
|
by: arne.muller |
last post by:
Hello,
I've come across some problems reading strucutres from binary files.
Basically I've some strutures
typedef struct {
int i;
double x;
int n;
double *mz;
|
by: Barry Flynn |
last post by:
Hi
I am working with a VB 2005 program which has been converted from VB6.
It writes data out to a flat file, with code like the following line
WriteLine(riFileNo, "Hist", lsAssetID,...
|
by: Skybuck Flying |
last post by:
Hello,
This morning I had an idea how to write Scalable Software in general.
Unfortunately with Delphi 2007 it can't be done because it does not support
operating overloading for classes, or...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
