Add tests to odbccp32

James Hawkins truiken at
Mon Jan 8 12:38:01 CST 2007

On 1/8/07, Bill Medland <billmedland at> wrote:
> On Mon, 2007-08-01 at 12:11 -0600, James Hawkins wrote:
> > On 1/8/07, Bill Medland <billmedland at> wrote:
> > > Bill Medland (billmedland at
> > > Add tests structure to odbccp32
> > >
> >
> > You need to add tests for this patch to be accepted.  Also, you've
> > labeled the test suite 'error'.  How many functions in odbccp32 are
> > you planning on testing in this file?  I see only SQLInstallerError
> > and SQLPostInstallerError in the spec file, which is not enough to
> > warrant a whole test file.  Please read other test files to get a
> > better of idea what needs to happen with these tests.
> >
> Why??

What's the point of adding code that does absolutely nothing?  In an
open source project, there's no guarantee that you'll come back and
finish what you started, though there are several other reasons why
this is not allowed.

> I was trying to make things easier for Alexandre.  If I write any tests
> in the patch then I need to write the code to ensure that we actually
> pass those tests (which we don't because we don't actually really do
> anything yet and then the patch ends up doing all three things; adding
> testing, adding the error reporting and then adding the actual function
> that I want to get working).

That is what todo_wine is for.  It sounds like you need to read the
developer documentation at

> My aim is:
> + to submit one trivial patch which adds testing; a no-brainer
> + to submit the code for the error stack and SQLInstallerError (so that
> when I add the function I want I will be able to do the error reporting
> straight off instead of the usual hack of "I'll do the error reporting
> when I get around to it in another two years time"
> + to submit the code for SQLGetInstalledDrivers (which is what I
> actually want to get done).
> And why can't I have error.c?  The purpose of error.c is to contain the
> tests of the error handling, as you surmised, so I feel that I named it
> well.  That is two functions, as you surmised.  However they constitute
> a well-defined subsystem of the dll so why should they not be in a
> separate file?

Two functions is definitely not a well-defined subsystem.  They are
helper functions and they don't need their own test file.

> How many tests?  Well, to start with I envisage about 10.  However as I
> said I believe that the measure is not the length; it is the modularity.

Ten tests is fine, but like I said, they don't need a separate file.

James Hawkins

More information about the wine-devel mailing list