mockobjects-java-dev

[MO-java-dev] SQL validation

[Greg M. <gre...@ya...>]

I recently had a brief discussion with a couple of
developers on the c2 wiki
(http://c2.com/cgi/wiki?MockObject) regarding database
testing & MockObjects.  Here is an excerpt:

<excerpt>
I'm curious - for those of you out there who are using
MockObjects to test JDBC code, do you typically have
at least one unit test which uses a "real" database
connection as a santiy check? Or do you keep live
connections out of the unit testing altogether,
letting this type of testing fall under the umbrella
of "functional testing"? While I like the speed and
focus of MockObjects for database testing, certain
things about it make me nervous, e.g. SQL statements
are not validated. --GregMerrill 

I'm currently getting big into database mock objects
with VbUnitThree. I'm currently ignoring the issue of
testing the real database objects. But I know this is
a mistake; I'll have to come back and write unit tests
for them, just like any other class. -- JeffGrigg 

OK, it bit me today: My unit tests didn't test the
SQL, and so didn't catch a stray column. But that's
OK, because the end-to-end functional tests (done in
the same unit testing framework, only less often),
caught the problem. No blood; no foul. (Yes, I still
need to write unit tests for the SQL. I will, I
will... ;-) -- jtg 
</excerpt>

My question to this list is: would anyone be
interested in an optional SQL validation feature on
relevant mock sql objects
(MockStatement/MockPreparedStatement)?  Something
along the lines of setExpectValidSQL(boolean)?  When
true, this property would validate the syntax of SQL
statements on calls to executeUpdate() &
executeQuery().  Very handy to ensure that
dynamically-generated queries don't have syntax
problems.

I've created a prototype of such a feature, using a
parser generated with JavaCC and a contributed grammar
(http://www.cobase.cs.ucla.edu/pub/javacc/).  It seems
to work OK.  (The grammar is a little Oracle-specific,
but should handle standard SQL just fine.)

Do you think this kind of feature would fit well in
the mock objects core?  Or does it seem more like an
optional feature which should be released/maintained
separately?  

And the bottom line - does basic SQL validation have a
place in MockObject-style unit testing?  Or should
this type of responsibililty lie with functional
testing, since the SQL validation which is actually
done at runtime is database-dependent?

-Greg Merrill


__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

RE: [MO-java-dev] SQL validation

[Vincent T. <Vin...@ge...>]

One easy thing to do to complement your MockObjects testing is to test your
expected SQL query string against the DB with a simple SQL query analyzer.
Once you are sure of your syntax (providing that your table definition
doesnt change) you can rely on MockObjects testing until functional testing.
That's what we do and it hasn't reserved any bad surprise ... yet :-)

 -Vincent-

-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Greg Merrill
Sent: Friday, November 16, 2001 4:29 PM
To: moc...@li...
Subject: [MO-java-dev] SQL validation


I recently had a brief discussion with a couple of
developers on the c2 wiki
(http://c2.com/cgi/wiki?MockObject) regarding database
testing & MockObjects.  Here is an excerpt:

<excerpt>
I'm curious - for those of you out there who are using
MockObjects to test JDBC code, do you typically have
at least one unit test which uses a "real" database
connection as a santiy check? Or do you keep live
connections out of the unit testing altogether,
letting this type of testing fall under the umbrella
of "functional testing"? While I like the speed and
focus of MockObjects for database testing, certain
things about it make me nervous, e.g. SQL statements
are not validated. --GregMerrill

I'm currently getting big into database mock objects
with VbUnitThree. I'm currently ignoring the issue of
testing the real database objects. But I know this is
a mistake; I'll have to come back and write unit tests
for them, just like any other class. -- JeffGrigg

OK, it bit me today: My unit tests didn't test the
SQL, and so didn't catch a stray column. But that's
OK, because the end-to-end functional tests (done in
the same unit testing framework, only less often),
caught the problem. No blood; no foul. (Yes, I still
need to write unit tests for the SQL. I will, I
will... ;-) -- jtg
</excerpt>

My question to this list is: would anyone be
interested in an optional SQL validation feature on
relevant mock sql objects
(MockStatement/MockPreparedStatement)?  Something
along the lines of setExpectValidSQL(boolean)?  When
true, this property would validate the syntax of SQL
statements on calls to executeUpdate() &
executeQuery().  Very handy to ensure that
dynamically-generated queries don't have syntax
problems.

I've created a prototype of such a feature, using a
parser generated with JavaCC and a contributed grammar
(http://www.cobase.cs.ucla.edu/pub/javacc/).  It seems
to work OK.  (The grammar is a little Oracle-specific,
but should handle standard SQL just fine.)

Do you think this kind of feature would fit well in
the mock objects core?  Or does it seem more like an
optional feature which should be released/maintained
separately?

And the bottom line - does basic SQL validation have a
place in MockObject-style unit testing?  Or should
this type of responsibililty lie with functional
testing, since the SQL validation which is actually
done at runtime is database-dependent?

-Greg Merrill


__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

_______________________________________________
Mockobjects-java-dev mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

Re: [MO-java-dev] SQL validation

[<moc...@li...>]

RnJvbTogIkdyZWcgTWVycmlsbCIgPGdyZWdobWVycmlsbEB5YWhvby5jb20+DQo+IE15IHF1ZXN0
aW9uIHRvIHRoaXMgbGlzdCBpczogd291bGQgYW55b25lIGJlDQo+IGludGVyZXN0ZWQgaW4gYW4g
b3B0aW9uYWwgU1FMIHZhbGlkYXRpb24gZmVhdHVyZSBvbg0KPiByZWxldmFudCBtb2NrIHNxbCBv
YmplY3RzDQo+IChNb2NrU3RhdGVtZW50L01vY2tQcmVwYXJlZFN0YXRlbWVudCk/ICBTb21ldGhp
bmcNCj4gYWxvbmcgdGhlIGxpbmVzIG9mIHNldEV4cGVjdFZhbGlkU1FMKGJvb2xlYW4pPyAgV2hl
bg0KPiB0cnVlLCB0aGlzIHByb3BlcnR5IHdvdWxkIHZhbGlkYXRlIHRoZSBzeW50YXggb2YgU1FM
DQo+IHN0YXRlbWVudHMgb24gY2FsbHMgdG8gZXhlY3V0ZVVwZGF0ZSgpICYNCj4gZXhlY3V0ZVF1
ZXJ5KCkuICBWZXJ5IGhhbmR5IHRvIGVuc3VyZSB0aGF0DQo+IGR5bmFtaWNhbGx5LWdlbmVyYXRl
ZCBxdWVyaWVzIGRvbid0IGhhdmUgc3ludGF4DQo+IHByb2JsZW1zLg0KPiANCj4gQW5kIHRoZSBi
b3R0b20gbGluZSAtIGRvZXMgYmFzaWMgU1FMIHZhbGlkYXRpb24gaGF2ZSBhDQo+IHBsYWNlIGlu
IE1vY2tPYmplY3Qtc3R5bGUgdW5pdCB0ZXN0aW5nPyAgT3Igc2hvdWxkDQo+IHRoaXMgdHlwZSBv
ZiByZXNwb25zaWJpbGlsdHkgbGllIHdpdGggZnVuY3Rpb25hbA0KPiB0ZXN0aW5nLCBzaW5jZSB0
aGUgU1FMIHZhbGlkYXRpb24gd2hpY2ggaXMgYWN0dWFsbHkNCj4gZG9uZSBhdCBydW50aW1lIGlz
IGRhdGFiYXNlLWRlcGVuZGVudD8NCg0KbXkgKGRvdWJ0bGVzcyBuYWl2ZSkgdGFrZSBvbiB0aGlz
IGlzIHRoYXQgaXMgdGhhdCBtb3N0IFNRTCBpcyBlaXRoZXIgc2ltcGxlIChwb3AgYSBjb3VwbGUg
b2YgdmFsdWVzIGluIGEgcXVlcnkpIG9yIGRyZWFkZnVsbHkgY29tcGxpY2F0ZWQuIEZvciB0aGUg
Zm9ybWVyLCBhbGwgeW91IHJlYWxseSBuZWVkIHRvIGNoZWNrIF9pbiB0aGUgdW5pdCB0ZXN0XyBp
cyB0aGF0IHRoZSByaWdodCB2YWx1ZXMgZ2V0IHBhc3NlZCB0aHJvdWdoLCB3aGljaCB5b3UgY2Fu
IHByb2JhYmx5IGRvIHdpdGggYSBzaW1wbGUgc3Vic3RyaW5nIG1hdGNoLiBUaGVyZSdzIGEgYml0
IG9mIGFuIGFydCB0byBzcGVjaWZpeWluZyB0aGUgbWluaW11bSB0aGF0IGlzIGltcG9ydGFudCBp
biBhIHVuaXQgdGVzdC4gRm9yIHRoZSBsYXR0ZXIsIHlvdSBwcm9iYWJseSB3YW50IGEgc2VwYXJh
dGUgb2JqZWN0IHRvIGdlbmVyYXRlIHRoZSBTUUwgd2hpY2ggd291bGQgYmUgdGVzdGVkIGF3YXkg
ZnJvbSB0aGUgSkRCQyAtLSBpbiB3aGljaCBjYXNlIHlvdXIgcGFyc2VyIG1pZ2h0IGJlIGFwcHJv
cHJpYXRlLg0KDQpPZiBjb3Vyc2UsIHRoaXMga2luZCBvZiBkZXZlbG9wbWVudCBhbHNvIHJlcXVp
cmVzIGEgaGlnaGVyLWxldmVsIHRlc3QgdG8gbWFrZSBzdXJlIHlvdSBoYXZlbid0IGRyaWZ0ZWQg
YXdheSBmcm9tIHRoZSBzY2hlbWEuIEZvciBhIHNtYWxsIGFwcGxpY2F0aW9uLCB0aGF0IHdvdWxk
IHByb2JhYmx5IGJlIHlvdXIgYWNjZXB0YW5jZSB0ZXN0cyAob3Igd2hhdGV2ZXIgd2UncmUgY2Fs
bGluZyB0aGVtIG5vdykuIEZvciBhIGxhcmdlIGFwcGxpY2F0aW9uLCB5b3UgbWlnaHQgaGF2ZSBz
b21lIERCIGludGVncmF0aW9uIHRlc3RzLg0KDQp0aGUgb3RoZXIgdGhvdWdodCB0aGF0IHN0cmlr
ZXMgbWUgaXMgdGhhdCB3ZSBrbm93IHRoYXQgdGVzdC1maXJzdCBjaGFuZ2VzIHRoZSB3YXkgd2Ug
d3JpdGUgb3VyIGNvZGUgKHRvIG1ha2UgaXQgdGVzdGFibGUpLiBJIHdvdWxkIGV4cGVjdCB0aGF0
IHdyaXRpbmcgZGIgYWNjZXNzIGZvciB0ZXN0YWJpbGl0eSB3b3VsZCBjaGFuZ2UgdGhlIHdheSB3
ZSB3cml0ZSBTUUwuIEhhcyBhbnlvbmUgbm90aWNlZCB0aGlzPw0KDQo+IEkndmUgY3JlYXRlZCBh
IHByb3RvdHlwZSBvZiBzdWNoIGEgZmVhdHVyZSwgdXNpbmcgYQ0KPiBwYXJzZXIgZ2VuZXJhdGVk
IHdpdGggSmF2YUNDIGFuZCBhIGNvbnRyaWJ1dGVkIGdyYW1tYXINCj4gKGh0dHA6Ly93d3cuY29i
YXNlLmNzLnVjbGEuZWR1L3B1Yi9qYXZhY2MvKS4gIEl0IHNlZW1zDQo+IHRvIHdvcmsgT0suICAo
VGhlIGdyYW1tYXIgaXMgYSBsaXR0bGUgT3JhY2xlLXNwZWNpZmljLA0KPiBidXQgc2hvdWxkIGhh
bmRsZSBzdGFuZGFyZCBTUUwganVzdCBmaW5lLikNCj4gDQo+IERvIHlvdSB0aGluayB0aGlzIGtp
bmQgb2YgZmVhdHVyZSB3b3VsZCBmaXQgd2VsbCBpbg0KPiB0aGUgbW9jayBvYmplY3RzIGNvcmU/
ICBPciBkb2VzIGl0IHNlZW0gbW9yZSBsaWtlIGFuDQo+IG9wdGlvbmFsIGZlYXR1cmUgd2hpY2gg
c2hvdWxkIGJlIHJlbGVhc2VkL21haW50YWluZWQNCj4gc2VwYXJhdGVseT8gIA0KDQpJdCBzb3Vu
ZHMgbGlrZSBhIHNlcGFyYXRlIGZlYXR1cmUgdG8gbWUuIERvIHBlb3BsZSB0aGluayBpdCBzaG91
bGQgYmUgaG9zdGVkIG9uIHRoZSBNb2NrIE9iamVjdHMgcHJvamVjdD8NCg0KU3RldmUNCg0K

RE: [MO-java-dev] SQL validation

[<moc...@li...>]

As we are all about testing - I would like to see someone put some work into
testing SQL this way - it sounds cool. As you pointed out steve - there is
an art to testing just the right amount so it would be interesting to see
how this works out - but in theory why not work on it here and see how it
pans out?

Tim

> the other thought that strikes me is that we know that test-first
> changes the way we write our code (to make it testable). I would
> expect that writing db access for testability would change the
> way we write SQL. Has anyone noticed this?
>
> > I've created a prototype of such a feature, using a
> > parser generated with JavaCC and a contributed grammar
> > (http://www.cobase.cs.ucla.edu/pub/javacc/).  It seems
> > to work OK.  (The grammar is a little Oracle-specific,
> > but should handle standard SQL just fine.)
> >
> > Do you think this kind of feature would fit well in
> > the mock objects core?  Or does it seem more like an
> > optional feature which should be released/maintained
> > separately?
>
> It sounds like a separate feature to me. Do people think it
> should be hosted on the Mock Objects project?
>
> Steve
>
> 2‡$¡¸ÞrÛ#jözùšŠX§‚X¬´Ê’†ãyËl«ÚuëåŠËl²‹«qç讧zØm¶›?þX¬¶Ë(º·~Šà
> zw­þX¬¶ÏåŠËbú?š‡$¡¸ÞrÛ#jö

RE: [MO-java-dev] SQL validation

[Greg M. <gre...@ya...>]

Why don't I finish the prototype & pass it along to
you guys.  Then you can decide if it's worth inclusion
in the project, and if so, in what capactiy.

--- moc...@li...
wrote:
> As we are all about testing - I would like to see
> someone put some work into
> testing SQL this way - it sounds cool. As you
> pointed out steve - there is
> an art to testing just the right amount so it would
> be interesting to see
> how this works out - but in theory why not work on
> it here and see how it
> pans out?
> 
> Tim
> 
> > the other thought that strikes me is that we know
> that test-first
> > changes the way we write our code (to make it
> testable). I would
> > expect that writing db access for testability
> would change the
> > way we write SQL. Has anyone noticed this?
> >
> > > I've created a prototype of such a feature,
> using a
> > > parser generated with JavaCC and a contributed
> grammar
> > > (http://www.cobase.cs.ucla.edu/pub/javacc/).  It
> seems
> > > to work OK.  (The grammar is a little
> Oracle-specific,
> > > but should handle standard SQL just fine.)
> > >
> > > Do you think this kind of feature would fit well
> in
> > > the mock objects core?  Or does it seem more
> like an
> > > optional feature which should be
> released/maintained
> > > separately?
> >
> > It sounds like a separate feature to me. Do people
> think it
> > should be hosted on the Mock Objects project?
> >
> > Steve
> >
> >
>
2‡$¡¸ÞrÛ#jözùšŠX§‚X¬´Ê’†ãyËl«ÚuëåŠËl²‹«qç讧zØm¶›?þX¬¶Ë(º·~Šà
> > zw­þX¬¶ÏåŠËbú?š‡$¡¸ÞrÛ#jö
> 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
>
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev


__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

Re: [MO-java-dev] SQL validation

[Steve F. <st...@m3...>]

V2UgY2FuIGFsd2F5cyBob3N0IGl0IHdoZW4geW91J3JlIHJlYWR5IGFuZCBzZWUgaWYgdGhlcmUn
cyBhbnkgdGFrZSB1cC4NCg0KU3RldmUNCg0KRnJvbTogIkdyZWcgTWVycmlsbCIgPGdyZWdobWVy
cmlsbEB5YWhvby5jb20+DQo+IFdoeSBkb24ndCBJIGZpbmlzaCB0aGUgcHJvdG90eXBlICYgcGFz
cyBpdCBhbG9uZyB0bw0KPiB5b3UgZ3V5cy4gIFRoZW4geW91IGNhbiBkZWNpZGUgaWYgaXQncyB3
b3J0aCBpbmNsdXNpb24NCj4gaW4gdGhlIHByb2plY3QsIGFuZCBpZiBzbywgaW4gd2hhdCBjYXBh
Y3RpeS4NCg0K

Re: [MO-java-dev] SQL validation

[Steve F. <st...@m3...>]

RnJvbTogPG1vY2tvYmplY3RzLWphdmEtZGV2LWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4N
Cj4gQXMgd2UgYXJlIGFsbCBhYm91dCB0ZXN0aW5nIC0gSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21l
b25lIHB1dCBzb21lIHdvcmsgaW50bw0KPiB0ZXN0aW5nIFNRTCB0aGlzIHdheSAtIGl0IHNvdW5k
cyBjb29sLiBBcyB5b3UgcG9pbnRlZCBvdXQgc3RldmUgLSB0aGVyZSBpcw0KPiBhbiBhcnQgdG8g
dGVzdGluZyBqdXN0IHRoZSByaWdodCBhbW91bnQgc28gaXQgd291bGQgYmUgaW50ZXJlc3Rpbmcg
dG8gc2VlDQo+IGhvdyB0aGlzIHdvcmtzIG91dCAtIGJ1dCBpbiB0aGVvcnkgd2h5IG5vdCB3b3Jr
IG9uIGl0IGhlcmUgYW5kIHNlZSBob3cgaXQNCj4gcGFucyBvdXQ/DQo+IFRpbQ0KDQpBY3R1YWxs
eSwgSSB0aG91Z2h0IHdlIHdlcmUgYWxsIGFib3V0IGRlc2lnbiwgdXNpbmcgdGVzdHMgdG8gZHJp
dmUgdGhlbSA7LSkgU28sIHdoYXQgZG8gd2UgZG8gbmV4dD8gSSdtIG5vdCBrZWVuIG9uIHJvbGxp
bmcgdGhpcyBpbnRvIHRoZSBiYXNlIFNRTCBsaWJyYXJ5IGJlY2F1c2U6DQotIG1vY2sgaW1wbGVt
ZW50YXRpb25zIHNob3VsZCBiZSBibGluZGluZ2x5IHNpbXBsZSBhbmQgdGhlIGdlbmVyYXRpb24g
b2YgIGFueSBTUUwgdGhhdCdzIHdvcnRoIHJlYWwgdGVzdGluZyBzaG91bGQgYmUgZmFjdG9yZWQg
aW50byBhIHNlcGFyYXRlIG9iamVjdA0KLSBkbyB3ZSB1bmRlcnN0YW5kIHdoYXQgd2UgbWVhbiBi
eSB0aGlzIGtpbmQgb2YgdGVzdGluZyB5ZXQ/DQoNClN0ZXZlDQoNCj4gDQo+ID4gdGhlIG90aGVy
IHRob3VnaHQgdGhhdCBzdHJpa2VzIG1lIGlzIHRoYXQgd2Uga25vdyB0aGF0IHRlc3QtZmlyc3QN
Cj4gPiBjaGFuZ2VzIHRoZSB3YXkgd2Ugd3JpdGUgb3VyIGNvZGUgKHRvIG1ha2UgaXQgdGVzdGFi
bGUpLiBJIHdvdWxkDQo+ID4gZXhwZWN0IHRoYXQgd3JpdGluZyBkYiBhY2Nlc3MgZm9yIHRlc3Rh
YmlsaXR5IHdvdWxkIGNoYW5nZSB0aGUNCj4gPiB3YXkgd2Ugd3JpdGUgU1FMLiBIYXMgYW55b25l
IG5vdGljZWQgdGhpcz8NCj4gPg0KPiA+ID4gSSd2ZSBjcmVhdGVkIGEgcHJvdG90eXBlIG9mIHN1
Y2ggYSBmZWF0dXJlLCB1c2luZyBhDQo+ID4gPiBwYXJzZXIgZ2VuZXJhdGVkIHdpdGggSmF2YUND
IGFuZCBhIGNvbnRyaWJ1dGVkIGdyYW1tYXINCj4gPiA+IChodHRwOi8vd3d3LmNvYmFzZS5jcy51
Y2xhLmVkdS9wdWIvamF2YWNjLykuICBJdCBzZWVtcw0KPiA+ID4gdG8gd29yayBPSy4gIChUaGUg
Z3JhbW1hciBpcyBhIGxpdHRsZSBPcmFjbGUtc3BlY2lmaWMsDQo+ID4gPiBidXQgc2hvdWxkIGhh
bmRsZSBzdGFuZGFyZCBTUUwganVzdCBmaW5lLikNCj4gPiA+DQo+ID4gPiBEbyB5b3UgdGhpbmsg
dGhpcyBraW5kIG9mIGZlYXR1cmUgd291bGQgZml0IHdlbGwgaW4NCj4gPiA+IHRoZSBtb2NrIG9i
amVjdHMgY29yZT8gIE9yIGRvZXMgaXQgc2VlbSBtb3JlIGxpa2UgYW4NCj4gPiA+IG9wdGlvbmFs
IGZlYXR1cmUgd2hpY2ggc2hvdWxkIGJlIHJlbGVhc2VkL21haW50YWluZWQNCj4gPiA+IHNlcGFy
YXRlbHk/DQo+ID4NCj4gPiBJdCBzb3VuZHMgbGlrZSBhIHNlcGFyYXRlIGZlYXR1cmUgdG8gbWUu
IERvIHBlb3BsZSB0aGluayBpdA0KPiA+IHNob3VsZCBiZSBob3N0ZWQgb24gdGhlIE1vY2sgT2Jq
ZWN0cyBwcm9qZWN0Pw0KPiA+DQo+ID4gU3RldmUNCj4gPg0KPiA+IDI/JKG43nLbI2r2nXr5c1NY
pyxYrLTKHCc/43nLbI2r2nXr5VPLbLI8q3Hn6K4Hp3rYbbY+P/5YrLbLKLq3Hn5T4A0KPiA+IHp3
rf5YrLbP5VPLYp36P3M/JKG43nLbI2r2nQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1vY2tvYmplY3RzLWphdmEtZGV2IG1haWxp
bmcgbGlzdA0KPiBNb2Nrb2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4g
aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbW9ja29iamVjdHMt
amF2YS1kZXYNCj4gDQo=

Re: [MO-java-dev] SQL validation

[Greg M. <gre...@ya...>]

> > And the bottom line - does basic SQL validation
> have a
> > place in MockObject-style unit testing?  Or should
> > this type of responsibililty lie with functional
> > testing, since the SQL validation which is
> actually
> > done at runtime is database-dependent?
> 
> my (doubtless naive) take on this is that is that
> most SQL is either simple (pop a couple of values in
> a query) or dreadfully complicated. For the former,
> all you really need to check _in the unit test_ is
> that the right values get passed through, which you
> can probably do with a simple substring match.
> There's a bit of an art to specifiying the minimum
> that is important in a unit test. For the latter,
> you probably want a separate object to generate the
> SQL which would be tested away from the JDBC -- in
> which case your parser might be appropriate.

This take is not naive, but is in fact quite
consistent with my experience.  I think queries
typically do fall into the two categories you mention:
trivially simple or flat-out ghastly.  I also agree
with the notion of "a separate object to generate the
SQL" in complex cases; for example, I use a "Query"
object with methods like addSelect(), addFrom(), and
addWhere().  Using this object helps ensure that for
complex queries, all the punctuation & conjunctions
separating various parts of the query end up in the
right places.

Nevertheless, mistakes are still occasionally made in
both the simple and complex types (particularly when
making changes to pre-existing code), and SQL syntax
errors just _feel_ to me like they should be
detectable earlier in the testing process.  I say this
because what is and isn't valid SQL syntax is not
going to change during the life of the project, as
something such as the db schema will.

> Of course, this kind of development also requires a
> higher-level test to make sure you haven't drifted
> away from the schema. For a small application, that
> would probably be your acceptance tests (or whatever
> we're calling them now). For a large application,
> you might have some DB integration tests.
> 
> the other thought that strikes me is that we know
> that test-first changes the way we write our code
> (to make it testable). I would expect that writing
> db access for testability would change the way we
> write SQL. Has anyone noticed this?

Interesting notion.  I think most folks currently test
db access which falls outside of the JDBC API (e.g.
the SQL itself) not with unit tests, but with
"acceptance tests" and "DB integration tests", as you
have mentioned.  Until unit-like facilities are
available in the db access domain, I don't imagine
we'll know the answer to this question.

> > I've created a prototype of such a feature, using
> a
> > parser generated with JavaCC and a contributed
> grammar
> > (http://www.cobase.cs.ucla.edu/pub/javacc/).  It
> seems
> > to work OK.  (The grammar is a little
> Oracle-specific,
> > but should handle standard SQL just fine.)
> > 
> > Do you think this kind of feature would fit well
> in
> > the mock objects core?  Or does it seem more like
> an
> > optional feature which should be
> released/maintained
> > separately?  
> 
> It sounds like a separate feature to me. Do people
> think it should be hosted on the Mock Objects
> project?

The more I think about it, the more I agree with you
on this point.  The Oracle-specificness of the grammar
alone suggests to me that this is not core
functionality.

-Greg

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com