Test framework requirements

This page is intended as the collection point for people to record their requirements of a new test-framework environment. The new test framework environment is intended to support Lustre today as well as into the future with exascale systems and so the entries on this page should encapsulate all that will be needed to test Lustre for the foreseeable exascale future. The current plan is that we should design the best possible new test framework environment and then assess if a transition from the current framework is possible, but we should not hinder the new framework environment in order to make the transition possible. Please add your requirements to the table below including child pages where you suggestion is a document or sizeable entry. We want to capture all the valuable input of people from ideas, to language requirements, high level architectural ideas, references to other test methods/language/environments that might be useful......

Email	Requirement/Idea/Thought	Why
[email protected]	The framework environment must cause scalable tests to be the natural way to write tests. The shortest and simplest test should be scalable, with singular non-scalable being more time consuming.	Historically test framework tests tend to address single clients against single oss and single ost, extra effort is required to create scaling tests - this behaviour is the inverse of what's required. A simple test should scale to 100,000+ clients, against 1000+ servers with no effort on behalf of the test writer.
[email protected]	Test need to be organised on a one test per file basis. This will lead easier to read code but more importantly enable a set of tests to be created that are guaranteed to be safe for a live system. The problem with running tests by filter is that people make mistakes if it's possible to assemble an install of 'safe' tests then we are removing the live ammunition from the situation.	Be able to create safe live test system test sets.
[email protected]	Remove all test relationships A significant issue with fully exploiting the test-framework is that tests have interdependences with one test being required before another test if that later is to succeed. A knock on effect is that setup / teardown of test requirements is often done by the first or last test in a sequence.	The requirement is that each test can be successfully run without a requirement for any other test to execute. This has the following knock on effects; • Setup / Teardown be separated entirely from the tests themselves and then the setup called only once before the first test requiring the provided functionality and then the teardown called only once after the last test requiring the provided functionality. • A general mechanism should be created that allows a safe mechanism for sections containing a number of separate tests to be bounded by a setup/teardown pair. The ‘trick’ here is that the setup/teardown must only occur if at least one of the requiring tests is actually run. REQ-1: Identify all dependent tests and create a change request ticket for each test or set of tests. This work may have already been carried out by Xyratex and so the requirement is to create a change request ticket for those found. REQ-2: Create a general mechanism that enables setup/teardown code to be separated from the tests and called in an efficient way. Submit this mechanism for review before implementing on each set of dependent tests. REQ-3: Implement changes for each set of changes described by the ticket in req-1, where applicable apply the mechanism created in req-2 to deal with each setup/teardown requirement. Submit each change for review and landing, during the landing process ensure that extra testing is carried out to validate the modified tests are operating correctly.
[email protected]	What	Why