Re: dblib unit tests

Il giorno lun, 24/11/2008 alle 17.36 -0500, James K. Lowden ha scritto:
> Hi Freddy, 
> 
> Frediano Ziglio wrote:
> > Il giorno lun, 17/11/2008 alle 20.33 -0500, James K. Lowden ha scritto: 
> > > I began to modify our unit tests to work with Microsoft's db-lib. 
> > > Some of our tests "pass" FreeTDS but fail with Microsoft's.  Some
> > > can't be compiled.  
> ...
> > > After modifying t0013 to work with Microsoft's library, it continues
> > > to work with FreeTDS.  (Whew!)
> 
> >   perhaps you are doing too much things at the same time :)
> 
> Could be, could be.  It's lonely at the top.  ;-)
> 
> > Some time ago I tested with Sybase APIs and results was not so bad...
> 
> I remember.  I'm doing some work on that side too.  
> 

well... I see the changes and I can't see many changes in unittests in
order to compile under windows... good!

> > I have no time to help you
> 
> We have an expression for that: "The faster I go, the behinder I get." 
> (There's no word "behinder" but it makes the point.)  Also:
> 
> 	God put me on this earth 
> 	to do a certain number of things
> 	before I die.  
> 
> 	At the rate I'm going, 
> 	I'll live forever.  
> 
> > Are you sure that our tests cannot be compiled just with MS headers ??
> 
> I don't think the headers needed that much modification.  But several
> tests fail.  As we approach 1.0, I think the tests have to be better, and
> they have to work on all three implementations (FreeTDS, Sybase, and
> Microsoft).  
> 

I think so.

> > I saw a note in ChangeLog but I didn't see commits to dblib unittests,
> > did you forget to commit?
> 
> I'll check when I get back to work.  Thanks for pointing that out.  
> 
> > You could commit the nmake Makefile into misc directory.
> 
> Actually, on reflection, I think I'll add it to src/dblib/unittests.  With
> a little more work, it should be possible to use nmake.exe to compile and
> link the unit tests against any implementation.  
> 
> My concern is the stream processing error that Ted Hayes reported on 11
> November.  It's been there a long time.  It will be hard to fix without
> changing libtds, and the change might affect all three API libraries. 
> More rigorous tests would have uncovered it before, particularly if they
> were cross-tested with the vendor implementations.  I conclude that only
> boring, meticulous testing will flush out the remaining db-lib
> compatibility problems and errors.  
> 

Well... I know :) ODBC is now more test-driven. Actually I check ODBC
unitest under windows about every month. I found a winexec command under
Linux that could help me to script everything. Some tests fails some
cause MS ODBC seems less ODBC-compliant compared to our driver (believe
or not!) and something for sligtly difference (so small that former MS
ODBC passed...)

I don't think Ted problem require many changes (I don't think libTDS
will change...). Perhaps is time to see done_handling test again... this
test... is not a test... it do some test but what it lack is results
checking... it mainly prints the state of dblib after every operation
without checking a given state, so it returns always success. Many time
ago (more than a year I think) I managed to add state test and fix our
dblib (results printed was quite different!).

freddy77