If you are better at Git than I am, please go steal my changes from: https://bitbucket.org/dahozer/tfs/changeset/ff224a236535f041d066c6c5ccfbc890b44b70e7
and make a proper Gerrit commit (see http://gerrit.openafs.org/#change,6843 ) On Sun, Sep 16, 2012 at 10:14:48AM -0400, Jason Edgecombe wrote: > 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
