Add tests to odbccp32
billmedland at shaw.ca
Mon Jan 8 12:50:45 CST 2007
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
> > 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.
(Yes, I am upset)
Bill Medland <billmedland at shaw.ca>
More information about the wine-devel