[OpenAFS-devel] Testing (and a call for volunteers)

[Simon Wilkinson]

There's been a lot said on the list lately on the subject of testing, =
but very little technical information. I thought that it might be worth =
summarising the current state of the OpenAFS test suite, and to provide =
some suggestions for how people could help make it better. Writing tests =
is a pretty simple way of contributing to the whole OpenAFS effort.

The problem we've had, historically, is that there's a lot of =
configuration information hard coded into OpenAFS servers. It was hard =
to start them up as a user other than root, hard to run them on a =
non-standard port, and hard to provide them with configuration files =
from places other than the default location. This is now improving - YFS =
has paid for, and contributed, changes to the vlserver and the ptserver =
which allow them to be run as any user, and to use non-standard database =
and configuration file locations. This means that it is now possible to =
exercise these servers through the automated suite.

Also from YFS, there is a load of support code to make running, starting =
and stopping these servers easier. This all lives in tests/common

All of this means that it should be easy to start improving our test =
coverage of both of these servers. If anyone has a few spare moments and =
wants to improve our testing, adding a few more tests to either the =
vlserver and ptserver suites would be a great place to start.

Longer term, I hope to modify the fileserver and volserver so that we =
can run these from the test suite as well. This is harder, because they =
have a large number of preconfigured paths and assumptions that makes it =
tricky to launch them from an arbitrary developers account and tree. =
However, once this is done, we'll be able to launch a complete AFS cell =
as part of make check.

Of course, none of this will cover the cases that Jeffrey and David have =
been talking about. Many of the bugs that we encounter in production =
with AFS are incredibly complex - they rely on timing or load issues =
that just can't be simulated in a single machine environment. Other =
tests require particular versions of clients and servers, or on servers =
being modified to exhibit particular buggy behaviour.

That said, improving make check has value, even if it just frees up =
resources to concentrate on these trickier bugs. Even basic =
functionality tests in make check help us ship better releases.

If you are interested in writing some tests, feel free to ask me for =
more information!

Cheers,

Simon