Add tests to odbccp32

[James Hawkins]

On 1/8/07, Bill Medland <billmedland at shaw.ca> wrote:
> On Mon, 2007-08-01 at 12:38 -0600, James Hawkins wrote:
> > On 1/8/07, Bill Medland <billmedland at shaw.ca> wrote:
> > > On Mon, 2007-08-01 at 12:11 -0600, James Hawkins wrote:
> > > > On 1/8/07, Bill Medland <billmedland at shaw.ca> wrote:
> > > > > Bill Medland (billmedland at shaw.ca)
> > > > > 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
> > http://winehq.org/site/docs/winedev-guide/index
> >
> > > 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.
> >
> Ah, heck.  I submit one patch and get the usual deathly silence as to
> whether it has been rejected outright or whether it is being put to one
> side for a few days.
>
> So I try splitting it up so that Alexandre's decisionmaking is easier
>
> And this is what I get for it.
>
> I have better things to do with my time.
>
> I will stop trying to simplify things.
>
> If Alexandre wants to accept the version I submitted on Friday, fine.
> If not then it;s no sking off my nose.
>
> Bye
>
> (Yes, I am upset)

It's not really worth getting upset about.  Developer's patches get
rejected sometimes...it happens.  That's a good thing though, as it
keeps the Wine code base free of hacks and bad code.  The best thing
you can do is to be flexible and take the advice of fellow developers.
 As a community, it's up to everyone to comment on patches coming in
and do a pre-screen to lighten the load on Alexandre.  I know that he
won't accept this patch as it is, so I gave you advice on how to make
it acceptable.

-- 
James Hawkins