On Mon, 2007-08-01 at 12:11 -0600, James Hawkins wrote:
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
Bill Medland (billmedland@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?? 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). 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? 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.