Re: call for creating test suite

If you talk about a description in a text file, how do you interpret
that description in
an application to do that test ?

In my understanding, each description has a fixed format - eg. a
language. The simplest
one I could mention here may be ini:

[Test XYZ]
Param1 = Value1
Param2 = Value2
ParamN = ValueN

You may be able to generate these description data by scanning mylog
data. But in
my mind, the result is like a language a specific parser could
understand.

Regardles, how you would create the input files - detecting a login
scenario in mylog,
you would create a login test file reflecting that scenario.

When did you know, a new scenario has begun in mylog ?

I think, reverse engeneering the mylog to a description or script in a
language is very
difficult to handle and maintain.

I don't know the format of mylog, but I know how difficult it is to
scan log files - even only
to pick out some aspects only.

Who understands these mylog files ?

If I think about a plugin, I think about extensibility of the test
suite - regardless of the
language of implementation.

And more, if you want to compare a test between different databases,
who maintains
the generation of new tests from foreign logfile formats ?

What I mean, is, a programmer who uses ODBC API, may use typical
scenarious.
Like login, select, update, start/stop transactions. All these have a
typical call sequence
of ODBC API functions.

That is, what I mean with code peaces.

If you use these peaces to test pgSQL against, you can find bugs in the
implementation
of new stuff or unknown bugs that appear while you fixing other bugs.

The ODBC API dictates typical usecases. I think, these should be a
reference for tests.

New features in the ODBC driver should end up in a test for that
feature, thus extention.
I mean, if the infrastructure is available, it would be easy to extend.
Also it would be
easy to contribute new ones that don't break tested ones.

I hope to be constructive :-)

Regards,

Lothar