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.
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
it takes is to fix a typo in the external tool output or do a gentle
upgrade to it. Keeping the tests in runnable and working state would
truly become a Sisyphus work. For that reason, I think it should be a
priority to keep the tests self-sufficient and their scope to just the
exact source code and its build, and only rely on completely standard
tools. That way, if someone breaks tests by doing some notable change
that will slightly modify the disk format, they can fix the test in the
same or next commit.
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.
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?
In fact, as test support goes, there might be other changes very useful
for tests. For example the current doslabel test takes ages, because
after each change on the file, partition tables are being reloaded
(which does not make a lot of sense with file instead of disk). I
noticed that fdisk kind of tries to detect whether file is a block
device and skip the detection, but that code is probably broken at the
moment.
The fdisk after refactoring should be able to produce the same PT(s) like
the old fdisk and the all outputs should be also same. That's all.
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.
--
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
