[unixODBC-dev] SAP ODBC test porting

Eric Sharkey sharkey at netrics.com
Fri Mar 25 03:12:37 GMT 2005


> Sure; I can do this. What exactly do you have in mind? Something like;
> 
> SUCCESS    - success - keep going
> WARNING   - warning - keep going
> FAILURE    - failure - stop
> IGNORE   - warning or failure - keep going
> 
> The prompt option sounds like a good thing while a test suite is being 
> debugged but not for normal use (I think).

Right.  You don't want prompting during an automated regression test
run.  Basically, I was envisioning a setting in the top level index.ini
which would control what tst.pl does in response to test exit codes.

If a test fails, it returns the failure exit code.  Right now, tst.pl
just prints [FAILED] and goes on.  I'd like some way of controlling
that behavior.  Running 150 tests at once and seeing all the error
codes scroll by far faster than I can read isnt ideal.

As far as the error codes themselves, it's probably best to have
an easily extensible table, rather than a handful of fixed values.

> As for the non-standard SQL. I have two minds on this. One says leave 
> the SAP stuff in there and consider these to be mostly SAP tests (at 
> least the ones with SAP specific SQL). The other says that we should 
> only be concerned with generic tests.

I haven't seen anything I'd call SAP specific yet.  Mostly, I'm talking
about stuff which is MySQL specific.  For example, in timestamp.c,
there's this code I've changed in my working directory:

Index: timestamp.c
===================================================================
RCS file: /cvsroot/unixodbc/unixODBC/tests/v3/conformance/Other/timestamp/timestamp.c,v
retrieving revision 1.4
diff -r1.4 timestamp.c
129c129
<   retcode = SQLPrepare (hstmt, "insert into "TABLE" set t = ?", SQL_NTS);
---
>   retcode = SQLPrepare (hstmt, "insert into "TABLE" VALUES (?)", SQL_NTS);

In order for these tests to be generally useful, I don't think we
can keep MySQL SQL extensions in the tests, especially when they
serve no real purpose (meaning there is a simple standard way to
accomplish the same thing).

What do you think?

Eric



More information about the unixODBC-dev mailing list