Re: [Firebird-test] Catching up on postings

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

Hi,

Well, yes, I already started talking about it.

I have nearly completed a java scripting/testing solution based on xml
script/test files.  It can include the results of db access in the xml
file, and compare the current results with a stored reference.  Being
written in java, it will be easy to extend to test parallel db access. 
Obviously it is best adapted to testing via jdbc drivers, but I think it
might be worthwile investigating how hard it would be to write adapters to
use odbc drivers, IBO, and possibly generating dynamic and static sql c or
c++ programs.  I think having a single cross platform execution engine
would be rather desirable.  I don't know how to do this except in java.  I
don't think reliance on isql is appropriate.

Translating the TCS tests to any other format is going to be a large amount
of work.  Its easy enough to dump say each test into an xml file, but
extracting the sql and expected results into a more reasonable format will
be time consuming.  The NIST tests look only slightly easier to move to a
different system than TCS.

Would a provisional dtd for what I am working on and sample document be
helpful? Both are subject to change by me before I show the code, but
should give an idea of what I'm after.

thanks
David Jencks



On 2001.05.14 00:25:27 -0400 "Leyne, Sean" wrote:
> All,
> 
> First, please allow me to apologize for not reading the postings sent
> over the last couple of days prior to sending my "plan for discussion"
> posting.  I wasn't used to much activity in this list and didn't even
> think to check.
> 
> While I am impressed with the discussions that have taken place, I think
> we need to establish the goals which need to be address by the testing
> processes.
> 
> I see the goals as:
> 
> 1)	Users running the testing programs should be insulated from the
> actual implementation/coding of the programs.  They should be able to
> download a ZIP/TAR with contains an executable, run it, review the
> results and perhaps create new scripts.
> 
> 2)	The execution of the testing program should involve a minimal
> installation footprint; the db client is expected, installing a C++
> compiler should not be.
> 
> 3)	All of the testing programs (including any script editors)
> should portable, to run on any platform which the engine runs on.
> 
> 4)	Any choice of development tools (Delphi, C++, Python, Java or
> MS
> C# <big grin>) should carefully consider the overall expertise of the
> project members.  
> 
> Other goals?
> 
> 
> Next, in order to decide how to proceed, we need to understand what the
> scope of the TCS suite functionality.  I, personally, don't understand
> why the current suite required such a elaborate shell/scripting
> environment and how that fit's in to the script which are executed.
> Perhaps someone could write up a explanation for all the member of the
> list -- so that we all understand who the piece are currently
> constructed.  Any volunteers?
> 
> 
> Finally, I would suggest that before we go writing any code that we need
> to explore the options available to us.  The options which have been
> mentioned so far include:
> 
> - modifying the current TCS suite
> - PostgreSQL testing suite
> - NIST suite
> - XP test framework
> - Open Source Database Benchmark (http://freshmeat.net/projects/osdb/)
> - CppUnit 
> 
> Any other suggestions?
> 
> 
> Sean
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/lists/listinfo/firebird-test
>