Hello,

is here someone who will create testsuite for psqlodbc driver?
I have this idea:

- it contains executable, and dir with text files
- each text file describe one test
- text file contains specification:
- test name
- what is the right result (failure with specified sqlstate could
be the right result)
- SQLXXX odbc commands with parameters which will be executed
in same order they are written to text file
- executable
- goes throught test dir execute each test and copare expected
result (readed from text file) againist real result for each
test; it takes in mind if the failure is on the last SQLXXX
- it stops on first error which is raised during execution of text
file
- write if each test is ok or not ok to stdout

Comments and volunteers are welcome.
This could improve bug hunting and checking if there is no known
bug in new release or development snapshot.

Please help us,

Luf

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Ludek Finstrle <luf@pzkagis.cz> writes:

> is here someone who will create testsuite for psqlodbc driver?

Isn't it possible to re-use/build upon some existing ODBC test suite?
Since ODBC is a standard interface, it would look like a waste to
duplicate such an effort across different ODBC drivers.

At worst a postgreSQL test-suite should hold ONLY postgreSQL-specific
tests, setup scripts, patches, etc., but no "standard" tests IMHO.

We (continuent) surely could invest some time developing such a suite
provided we can easily run it against our software.

There already is something that looks a lot like an ODBC test suite in
the 'tests' directory of unixODBC. Anyone had a look at it/heard about
it?



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> > is here someone who will create testsuite for psqlodbc driver?
>
> Isn't it possible to re-use/build upon some existing ODBC test suite?
> Since ODBC is a standard interface, it would look like a waste to
> duplicate such an effort across different ODBC drivers.

It's possible. I only specify what I want from it. I don't know other
odbc test suites.
If it fits my requirements it'll be simple to reproduce error from
log output of psqlodbc in the future. I think we process log output
through grep, awk and we get the input for test suite.

I'm open to discussion about the test suite fetures and architecture.
I post it here in this case too.

> We (continuent) surely could invest some time developing such a suite
> provided we can easily run it against our software.

Maybe I understand this bad. Are you volunteer?

> There already is something that looks a lot like an ODBC test suite in
> the 'tests' directory of unixODBC. Anyone had a look at it/heard about
> it?

No, I don't know it. Could you explain it to us? Everyone who feel that
we may use another ODBC test suite is welcome with his opinion and
his knowledge.

If someone would write it afresh the test suite could be written whatever
language you want. I think about PERL as it could be the fastest and
easiest way for me. But anyone could feel free to use what he want (after
discussion here).
I don't need the test suite know the constants. I get the values
so it could only know integral numbers, real numbers (maybe not
I don't know whole ODBC spec), string and maybe some other basic
types.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Ludek Finstrle <luf@pzkagis.cz> writes:

>> We (continuent) surely could invest some time developing such a suite
>> provided we can easily run it against our software.
>
> Maybe I understand this bad. Are you volunteer?

Yes, we will contribute to any test suite that fits our needs enough
for us to use it regularly (I guess that's how things usually
go!). One of our requirements is that it should NOT be too strongly
tied to a specific DBMS (postgreSQL or other).


>> There already is something that looks a lot like an ODBC test suite in
>> the 'tests' directory of unixODBC. Anyone had a look at it/heard about
>> it?
>
> No, I don't know it. Could you explain it to us? Everyone who feel that
> we may use another ODBC test suite is welcome with his opinion and
> his knowledge.

I haven't look at it yet, only planned to. Unless it's terribly
written/not flexible, it should be faster to start from this than to
reinvent the wheel.


> If someone would write it afresh the test suite could be written whatever
> language you want. I think about PERL as it could be the fastest and
> easiest way for me.

You gonna like it: I heard that unixodbc/tests use perl intensively.


> I don't need the test suite know the constants. I get the values
> so it could only know integral numbers, real numbers (maybe not
> I don't know whole ODBC spec), string and maybe some other basic
> types.

Which constants are you talking about?


Cheers,

Marc.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Friday 13 January 2006 14:50, Ludek Finstrle wrote:
> If someone would write it afresh the test suite could be written whatever
> language you want. I think about PERL as it could be the fastest and
> easiest way for me. But anyone could feel free to use what he want (after
> discussion here).

A year or so ago I wrote a proglet (in C) to do some basic ODBC retrieval...
it was used as part of a test framework to do some simple queries and check
that the expected data was being returned from the database.

I guess this might be useful for PostgreSQL ODBC testing.

I'll hunt out my code over the weekend and see if its still usable.

Greetings from (frozen) Luxembourg.

--
David Somers
SIP: FWD dial **44808449868206; voipuser.org dial 08449868206
PGP Key = 7E613D4E
Fingerprint = 53A0 D84B 7F90 F227 2EAB 4FD7 6278 E2A8 7E61 3D4E

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDx+4nYnjiqH5hPU4RAlrpAJ9oJN0BrWL/XchtTbAqx3/xorEcigCgh2Lg
UAe3i3XmFLem3cHDSCjzGj4=
=7E3k
-----END PGP SIGNATURE-----

> Yes, we will contribute to any test suite that fits our needs enough
> for us to use it regularly (I guess that's how things usually
> go!). One of our requirements is that it should NOT be too strongly
> tied to a specific DBMS (postgreSQL or other).

Well, nice to hear it. Thank you. I don't need tied test suite to DBMS.
Only text files (or what we discuss here) have to be in some kind
specific. The next question is the license of the test suite.

> >> There already is something that looks a lot like an ODBC test suite in
> >> the 'tests' directory of unixODBC. Anyone had a look at it/heard about
> >> it?
> >
> > No, I don't know it. Could you explain it to us? Everyone who feel that
>
> I haven't look at it yet, only planned to. Unless it's terribly
> written/not flexible, it should be faster to start from this than to
> reinvent the wheel.

It sounds well.

> > If someone would write it afresh the test suite could be written whatever
> > language you want. I think about PERL as it could be the fastest and
> > easiest way for me.
>
> You gonna like it: I heard that unixodbc/tests use perl intensively.

It was only idea that string parsing and hashes in PERL are easy to
write.

> > I don't need the test suite know the constants. I get the values
> > so it could only know integral numbers, real numbers (maybe not
> > I don't know whole ODBC spec), string and maybe some other basic
> > types.
>
> Which constants are you talking about?

I mean that there is no entry in text files like this:
SQLEndTran(SQL_HANDLE_DBC,<handle>,SQL_COMMIT)
it would be
SQLEndTran(2,<handle>,0)

SQL_HANDLE_DBC is ODBC constant with its value = 2.

Egh I forgot that we have to get new handle and replace the old handle
with new one. Or similar support od ODBC handles.
I mean the test suite have to can get results and output params from
SQLXXX calls which need it (e.g. SQLAllocHandle).

So next request for test suite is support in text files something like:
SQLAllocHandle (1,0,@) (-,-,<handle>)
You don't have to follow this syntax exactly. It only mean that SQLXXX
calls could have to parameter sets. There are input parameters in first ()
and there are are output parameters in second (). @ means only output param,
- means only input param. We have to remember to handle the ODBC handle
specially. There can be more specialities. It need go throught ODBC spec
and define it fully.

I only specify what I know. The inspiration from unixODBC test suite
could be very good.

Regards,

Lud

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Am 12 Jan 2006 um 15:59 hat Ludek Finstrle geschrieben:

> Hello,
>
> is here someone who will create testsuite for psqlodbc driver?

Hi,

as for my problems with updateable cursors and driver versions, I
have extracted some code from my ODBC wrapper classes to be
a simple C test application with the same 'workflow' as of my GUI.

It is based on Dave's google posting and I could clearlier see if my
wrapper implementation is correct:

http://groups.google.com/group/pgsql...ead/df155225d9
d4a291/e9903c90492969b2#e9903c90492969b2

Here you could grab the code:

http://cvs.sourceforge.net/viewcvs.p...atabase/Plain-
ODBC-Test/test.cpp?rev=1.5&view=markup

It works on Windows/Linux/Mac OS X.

It has no very magic code to be copyrighted. So I think it should be GPL if Dave
agree.

Regards, Lothar

--
Lothar Behrens | Rapid Prototyping ...
Rosmarinstr 3 |
40235 Düsseldorf | www.lollisoft.de




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Fri, Jan 13, 2006 at 04:33:38PM +0100, Marc Herbert wrote:
> Ludek Finstrle <luf@pzkagis.cz> writes:
> >> We (continuent) surely could invest some time developing such a suite
> >> provided we can easily run it against our software.
> >
> > Maybe I understand this bad. Are you volunteer?
>
> Yes, we will contribute to any test suite that fits our needs enough
> for us to use it regularly (I guess that's how things usually
> go!). One of our requirements is that it should NOT be too strongly
> tied to a specific DBMS (postgreSQL or other).

Is there some progress? Or do you have some time plan? Or ...?

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> - it contains executable, and dir with text files
> - each text file describe one test

Sounds like a language to be defined first. If I would create a test
suite, first I would
find the smallest peaces of code to be implemented in a native language
like C or C++.

These peaces reflect typical or untypical usecases of the SQLXXX API.

As I have some experience using plugins, I would suggest to implement
these test
peaces as plugins to be loaded by the name of the test.

To have more flexibility, I would define a language to get test data
for it, but delegate
the handling of the test to the plugin.

Regards,

Lothar

Thu, Feb 02, 2006 at 03:26:26AM -0800, lothar.behrens@lollisoft.de napsal(a):
> > - it contains executable, and dir with text files
> > - each text file describe one test
>
> Sounds like a language to be defined first. If I would create a test
> suite, first I would
> find the smallest peaces of code to be implemented in a native language
> like C or C++.

I don't think so. We need to describe what we want. Then we could choose
the best suitable language for it. Maybe it is C or C++ or Perl or
whatever suite the developer.

> These peaces reflect typical or untypical usecases of the SQLXXX API.
>
> As I have some experience using plugins, I would suggest to implement
> these test
> peaces as plugins to be loaded by the name of the test.

It isn't easy to add new test (plugin). When we could describe each test
with text file (which could be automatically generated from mylog output)
we could easy add the new test to testsuite. So each new release has
no old bug. When we'll collect enough tests we have rock solid ODBC driver.

> To have more flexibility, I would define a language to get test data
> for it, but delegate
> the handling of the test to the plugin.

BTW we get the most flexibility by using ODBC API calls with parameters
obtained from mylog output. We cover all the situations this way.

I'm not sure now if I undestand you well. What do you mean with
"language to get test data"?

Regards,

Luf

P.S. I'm sorry if I misunderstand you.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org