|
From: MAIL <fl...@we...> - 2002-10-09 06:21:14
|
> On Wed, Oct 09, 2002 at 02:25:06AM -0300, MAIL wrote: > > Well, it seems logical that the best test is really if windoze accepts our > > changes to the FS or not... maybe we should write testers in windoze, and run > > them from windoze. > > While this is right in principle, it is still good to provide some > other alternatives, because: > * windows might silently fail. > * windows might silently correct errors. > * rebooting into windows is slow. Unit tests are more useful if they > are easy to run. Yeah, good point. Windoze testers would be slow to use and would have to be complemented by linux user space testers anyway. > Other alternatives: > * ntfsfix > * diff(1) > * simple test cases where we can prepare input and expected output after > an operation. The e2fsck unit tests work like this... take a look! OK, I'll mark to take a look at those unit tests. One thing I didn't mention in my post is that the ideal scenario is to have the unit testers test individual functions of the API. I'm not sure this is feasible with this type of code (do I need to say I never did kernel development before?). Like, for each API function that writes to the NTFS, we write a tester that prepares the test (mounts FS, etc), calls just that API function, then checks the result. Probably doesn't work with this type of code... I imagine most of the API functions would corrupt the fs if called by themselves. I'll start looking at the API to get a feeling for that. Fabio |
