On Tue, Aug 11, 2009 at 12:54:25AM +0200, Zdenek Behan wrote:
> On 08/10/2009 04:20 PM, Karel Zak wrote:
>> You needn't to count any checksum, you can parse PT(s) and prints results
>> (e.g. "fdisk -l", "partx -l" or "parted print"). I think it should be
>> enough.
>>
> 1) That would naturally have to either call an external fdisk not from
> the current build, or would kind of kill the whole point, because broken
> fdisk can very easilly read its own broken output correctly.
See arbitrary regression test, it's almost always a check for a diff
between old and new output. We use it for filesystems detection (and
I will use it or PT parsing too). It might not be perfect, but...
Note that we still need to test the output from fdisk(s) for
regressions -- it's part of our API. Many people use the outputs in
their scripts.
> 2) Also, relying on external tools for tests like this can easilly break
> the tests without doing any modifications to the code being tested. All
Yes, then the external tool is broken and should be fixed.
Anyway, I think that 1) is better solution than 2).
> I picked md5sum of the disk image because it's independent on tools
> being used - partition table either is or isn't correct, and while
> variations of the same PT may be possible, one tool following identical
> steps will typically create identical images, with only notable
> exception being things that are supposed to be randomly generated by
> definition.
Well, if you really want to use checksums and you know offset and
size of random bytes you can remove it from the image by sed (or so)
and then count the checksum.
> I was thinking a simple option could implemented into the original code,
> allowing setting of the disk ID's for other labels, eliminating the
> issue. But it's a functionality change intended to merely support the
> tests, and that might simply not be desired. What do you think?
It's normal to add
#ifdef TEST_PROGRAM
main() {...}
#endif
to arbitrary .c file and use the program in regression tests. This
simple solution allows to test internal application/library stuff. We
already use it in shlibs/* mount/* login/* ....
> Indeed, but I think that tests should not be created just to make sure
> one certain code transformation goes right, and be useless otherwise.
> They should excercise the code no matter what is being done to it, and
> make sure that the output/function meets certain criteria.
That's always compromise... now you know why review-able patches
are so important :-), we cannot rely on the tests only.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
