On 09/16/2012 05:11 AM, Simon Wilkinson wrote:
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!
Simon,
I'm interested. How do I start? I was looking into the tests and "make
check" fails with the error:
libtool: link: cannot find the library
`/home/jwedgeco/openafs/openafs-git/openafs/src/opr/liboafs_util.la' or
unhandled argument
`/home/jwedgeco/openafs/openafs-git/openafs/src/opr/liboafs_util.la'
make[2]: *** [vos-t] Error 1
make[2]: Leaving directory
`/home/jwedgeco/openafs/openafs-git/openafs/tests/volser'
make[1]: *** [check] Error 1
make[1]: Leaving directory
`/home/jwedgeco/openafs/openafs-git/openafs/tests'
make: *** [check] Error 2
Thanks,
Jason
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
