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
>
|
