Add tests to odbccp32

[Bill Medland]

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)
-- 
Bill Medland <billmedland at shaw.ca>