On Mon, Feb 18, 2013 at 10:44:06AM +0530, Hemanth Kumar wrote: > On Sat, Feb 16, 2013 at 2:29 AM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > > Here's a question -- what are you testing? (Not just here, but in > > general, with your test infrastructure) > > > > There are (at least) three classes of tests you could be doing: > > > > 1) Unit tests, which test individual functions within the code and > > ensure they do what they're meant to do. > > > > 2) Integration tests, which test the full end-to-end system. > > > > 3) Partial integration tests, which exercise the kernel > > filesystem code. > > > > 4) Partial integration tests, which exercise the userspace tools code. > > > > > > Now, clearly you're not doing (1) here. It's going to be hard to > > separate (2) from (3) and (4), but it's possible to write your tests > > to do more of one or of the other. (*) > > > > I am tying to write a script to test quota subsystem (qgroups) and > hierarchical quota as suggested by Arne Jansen. > Since i am trying to write a script to test a particular feature i guess it > falls under unit testing category No, unit testing would typically be testing one individual function in the code, independently of the rest of the code-base. e.g. a battery of very small simple tests which verify that the device_size() function in utils.c returns the correct value in all cases. When you say "test a particular feature", you haven't distinguished between testing the *kernel* feature (i.e. "does the kernel behave correctly?") and the *userspace* feature (i.e. "does the userspace tool make all of the checks that it should do, tell the kernel to do the right thing, and return useful information when something fails?"). It's hard to separate these two fully without effectively reimplementing some part of the other side, but the decision either way will make a difference as to the set of tests you end up implementing. > > xfstests clearly is much more geared to (3), and stresses the > > kernel filesystem implementation rather than the userspace tools. If > > you want to test the implementation of qgroups, it belongs in > > xfstests. If you want to test the userspace code, you need to make > > sure that (over all your tests) you cover every command-line option, > > and every different way of using the tool, and ensure that it does the > > right things. > > > > What you've written in this patch seems to be more about testing > > the kernel behaviour than the userspace tools, but it'd be good if you > > can put your work into the context I've just talked about above. > > > > More comments below... > > > > On Fri, Feb 15, 2013 at 06:35:41PM +0530, Hemanth Kumar wrote: > > > > > > Signed-off-by: Hemanth Kumar <hemanthkumar51@xxxxxxxxx> > > > --- > > > hq.sh | 33 +++++++++++++++++++++++++++++++++ > > > 1 file changed, 33 insertions(+) > > > create mode 100644 hq.sh > > > > > > diff --git a/hq.sh b/hq.sh > > > new file mode 100644 > > > index 0000000..6a0a820 > > > --- /dev/null > > > +++ b/hq.sh > > > > Rather cryptic filename here. > > > > If this is to be applied to btrfs-progs, I'd recommend putting all > > your test scripts in a test subdir, and a "test" target in the > > Makefile that invokes the tests. > > > > Can you elaborate on this part a bit more. Ignore my comment. As Dave Chinner pointed out, this is best integrated into xfstests. [snip] > > > > You may want to take a look at my earlier work on this, at: > > http://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg13153.html > > That should at least give you a basic infrastructure to work in. [snip] > Thank you, I will take a look at your script and continue my work. Again, don't bother -- Dave was right, and my assumptions about what xfstests was actually doing were wrong. Use xfstests instead. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- We believe in free will because we have no choice. ---
Attachment:
signature.asc
Description: Digital signature
