Re: winspool/tests: dump filename and version of the tested file

[James Hawkins]

On 1/17/06, Detlef Riekenberg  wrote:
> Changelog:
> - winspool/tests: dump filename and version of the tested file
> - use <name> for all includes

We generally have a policy of silence for the test suite unless a
failure occurrs.  Why do you need to output the version tested?

--
James Hawkins

winspool/tests: dump filename and version of the tested file

[Detlef Riekenberg]

Am Dienstag, den 17.01.2006, 14:18 -0600 schrieb James Hawkins:
> We generally have a policy of silence for the test suite unless a
> failure occurrs.

Then we need to update many Tests, which do not respect this.
> Why do you need to output the version tested?

I have a partial implemented complex test for winspool here:

1. EnumPrinterDrivers and search for a usable driver
2. Add this driver with a new name
3. Add a local Port to a File
4. Add a printer with 2 and 3
5. Add a job: StartDoc / StartPage
6. "Hello World"
7. EndPage / EndDoc
8. Inspect the output-File
9. Delete the Printer
10. Delete the Port
11. Delete the Driver

This Patch was a first step for 1. 
(to create a Driver-Whitelist; I'm using 2 fixed Drivers atm.)

winspool/tests: dump filename and version of the tested file

[Jakob Eriksson]

Detlef Riekenberg wrote:
> Am Dienstag, den 17.01.2006, 14:18 -0600 schrieb James Hawkins:
> > We generally have a policy of silence for the test suite unless a
> > failure occurrs.
>
> Then we need to update many Tests, which do not respect this.

+1.

winspool/tests: dump filename and version of the tested file

[James Hawkins]

On 1/18/06, Detlef Riekenberg  wrote:
> Am Dienstag, den 17.01.2006, 14:18 -0600 schrieb James Hawkins:
> > We generally have a policy of silence for the test suite unless a
> > failure occurrs.
>
> Then we need to update many Tests, which do not respect this.

I agree, but that doesn't mean we should add more traces in the
meantime.  There is one case where I think it's leaning towards the OK
side, though it still bugs me, and that is the
advpack:GetVersionFromFile tests.  There's really no way to determine
(easily) what the results for that function should be and then do an
OK on the results, so we output the results to make sure at least
something is going on.

--
James Hawkins

winspool/tests: dump filename and version of the tested file

[Detlef Riekenberg]

Am Mittwoch, den 18.01.2006, 13:28 -0600 schrieb James Hawkins:
> There is one case where I think it's leaning towards the OK
> side, though it still bugs me, and that is the
> advpack:GetVersionFromFile tests.

This test is in the wrong File (file.c and tests/advpack.c).
> There's really no way to determine (easily) what the results for
> that function should be and then do an OK on the results,

Maybe something like:

major = minor = 0x00dead00
GetVersionFromFile ..
and validate the Returned data with known limits 
(NT3.1 and win2003) 6.0 >= major >= 3.1

Or use GetFileVersionInfo / VerQueryValue to read the exact values from
the dll.

GetVersionFromFile does not test for files without resources
(GetModuleFileName on NULL for the advpack_test-binary as example) and
for nonexistent Files.

winspool/tests: dump filename and version of the tested file

[James Hawkins]

On 1/18/06, Detlef Riekenberg  wrote:
> Am Mittwoch, den 18.01.2006, 13:28 -0600 schrieb James Hawkins:
> > There is one case where I think it's leaning towards the OK
> > side, though it still bugs me, and that is the
> > advpack:GetVersionFromFile tests.
>
> This test is in the wrong File (file.c and tests/advpack.c).

The GetVersionFromFile tests were written before the files.c test was
written, but if you want to change it, you're more than welcome to,
but it's not a big deal.
> > There's really no way to determine (easily) what the results for
> > that function should be and then do an OK on the results,
>
> Maybe something like:
>
> major = minor = 0x00dead00
> GetVersionFromFile ..
> and validate the Returned data with known limits
> (NT3.1 and win2003) 6.0 >= major >= 3.1
>
> Or use GetFileVersionInfo / VerQueryValue to read the exact values from
> the dll.

This is of course the non-easy way I was referring to, but I should
really call it the non-trivial method.  We'd basically have to write a
function in the test suite called get_file_version that does what we
do in our implementation of GetVersionFromFile to get the file version
and compare it with the real results from GetVersionFromFile, but
that's way over the top.  Keep in mind that it still bugs me that we
use trace even for this test, because unless you're debugging the
function, no one really looks at the results of the trace.
> GetVersionFromFile does not test for files without resources
> (GetModuleFileName on NULL for the advpack_test-binary as example) and
> for nonexistent Files.

I don't really see what you're getting at here.  Are you suggesting we
should add these tests?  Same thing as above, you're more than welcome
to add the tests.

--
James Hawkins