WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.
Testing Lustre Code: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
We recommend a "test early, test often" approach to testing. | We recommend a "test early, test often" approach to testing. | ||
| Line 8: | Line 7: | ||
''Note:'' You can use the OBD_FAIL_CHECK() or OBD_FAIL_TIMEOUT() hooks in Lustre to monitor failures. | ''Note:'' You can use the OBD_FAIL_CHECK() or OBD_FAIL_TIMEOUT() hooks in Lustre to monitor failures. | ||
Before you submit code, it must pass the Lustre acceptance test suite called "acceptance-small". | We provide several tools to help with testing Lustre code: | ||
* A Lustre testing framework from which a suite of acceptance tests called "acceptance-small" can be run is described in the next section. | |||
* Instructions for using a POSIX Compliance Suite for texting a Lustre file system is described in [[POSIX Testing]]. [[Is this related to testing code or should it go elsewhere?]] | |||
== Using the Lustre Testing Framework == | |||
Before you submit code, it must pass the Lustre acceptance test suite called "acceptance-small". We recommend you run the test suite often so that you can find out as soon as possible if your code is resulting in a regression. | |||
[[You can run it directly on your system from the lustre/tests directory.]] | |||
''Note:'' Please set the "acc-sm passed" flag on the attachment for each individual branch that was tested in Bugzilla to indicate this. [[refer to submitting code topic]] | ''Note:'' Please set the "acc-sm passed" flag on the attachment for each individual branch that was tested in Bugzilla to indicate this. [[refer to submitting code topic]] | ||
Revision as of 16:01, 29 August 2009
We recommend a "test early, test often" approach to testing.
If you are developing a new feature for Lustre, designing tests to exercise the new feature early in the development process will allow you to test your code as you develop it.
If you are fixing a bug in Lustre, creating a regression test up front will ensure that you can reproduce the reported problem and then verify that it has been fixed. And it will save you the effort of testing the fix manually and then creating a separate regression test later to submit with your bug fix.
Note: You can use the OBD_FAIL_CHECK() or OBD_FAIL_TIMEOUT() hooks in Lustre to monitor failures.
We provide several tools to help with testing Lustre code:
- A Lustre testing framework from which a suite of acceptance tests called "acceptance-small" can be run is described in the next section.
- Instructions for using a POSIX Compliance Suite for texting a Lustre file system is described in POSIX Testing. Is this related to testing code or should it go elsewhere?
Using the Lustre Testing Framework
Before you submit code, it must pass the Lustre acceptance test suite called "acceptance-small". We recommend you run the test suite often so that you can find out as soon as possible if your code is resulting in a regression.
You can run it directly on your system from the lustre/tests directory. Note: Please set the "acc-sm passed" flag on the attachment for each individual branch that was tested in Bugzilla to indicate this. refer to submitting code topic
