Re: [Firebird-test] Catching up on postings

[David J. <dav...@ea...>]

Hi,
On 2001.05.15 15:57:47 -0400 reed mideke wrote:
> "Leyne, Sean" wrote:
> > 
> [...]
> > Ah, there's your problem!  You're using InterClient! <grin>
> > 
> > The only problem I have with your points above is that the initial
> focus
> > is on testing the engine functionality.
> > 
> > Using any data access layer (jdbc, odbc, IBO...) introduces into the
> > testing scheme possible 'artifacts'/errors related to the data access
> > layer and not engine functionality.
> > 
> Mot only that, it makes it impossible to test functionality which
> is not exposed by your particular access layer(s).

obviously true.
> 
> > The current ISQL approach virtually eliminated these type of errors,
> > saving testers from hunting down these 'false positive' results.
> > Furthermore, when it comes to diagnosing anomolies in data results,
> ISQL
> > has been used as the "gold standard" for determining whether a problem
> > is engine or data access layer related.
> > 
> Emm, actually, embedded GDML (i.e. GPRE) is the gold standard.
> isql only lets you test DSQL. 
> 

Yes, I agree GDML is the gold standard.  However, I suspect almost noone is
going to start using Firebird to use either GDML or embedded sql.  99% of
new users (I'm making this numer up, but do you disagree?) are going to use
ejbs, delphi + ibo, odbc, or plain jdbc.  So if the tests available for
these drivers pass, this will make almost everyone happy.  If they fail,
true it is harder to find the problem than if fewer layers are present. 
However, these are not unit tests, they are functional tests. If there is
an error, lets write a unit test on the broken part when we fix it.

As to the 'limited functionality' question, as far as I know the major
missing piece in the jdbc category is reasonable transaction support.  I
think this will be addressed by the new java jca driver.  I think multiple
database support can be addressed by using the catalog and possibly schema
fields in the metadata.  I would like to know what other important pieces
of functionality are missing from a full jdbc/jca driver.

I have also suggested that we might be able to write a simple tool that
took the sql statement, generated a c embedded sql program, compiled it,
got the results, and compared them to the standard. 
I think it is really important to keep the logical content of what we are
testing (sql + logical structure and content of resuts) separated from the
particular testing driver we are using.

david jencks

> [...]
> --
> Reed Mideke
> email: rfm(at)cruzers.com  -If that fails:  rfm(at)portalofevil.com
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/lists/listinfo/firebird-test
>