howtotest.rst 8.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176
  1. How to write test suite/case
  2. ============================
  3. Assumptions
  4. -----------
  5. The library and utility make several assumptions about the environment:
  6. - OS should be Unix or Linux
  7. - Password-less authentication should be setup on all systems
  8. - Required users are available (see ``pbs_config --check-ug``)
  9. - The PTL package should be installed on all systems
  10. - The file system layout should be same on all systems
  11. - PBS_CONF_FILE variable should be set on all systems
  12. Naming conventions, recommended practices, and guidelines
  13. ---------------------------------------------------------
  14. Write the test in a filename prefixed by ``pbs_`` followed by feature name
  15. ``pbs_<featurename>.py``
  16. Name of the test class should be prefixed by ``Test`` and followed by unique
  17. explanatory name ``Test<feature>``
  18. Each test case name should start with ``test_`` followed by lower case characters.
  19. ``test_<testname>`` Test case name should be unique, accurate & explanatory, but
  20. concise, can have multiple words if needed. The test cases running sequence is
  21. unordered (some claim that it is lexicographic ordering but it is best to not write
  22. your test suites based on such assumptions).
  23. Put every functionality that is common to all test cases in its own method,
  24. and consider adding it to the library or utility if it is a generic interface to
  25. PBS.
  26. PTL strongly follows PEP8 Python coding style. so please style your code to follow
  27. PEP8 Python codeing style. You can find PEP8 at https://www.python.org/dev/peps/pep-0008/
  28. Some info about PBSTestSuite
  29. ----------------------------
  30. Tests that inherit functionality from a parent class such as PBSTestSuite have
  31. available to them predefined functionality for setUpclass, setUp, tearDownclass, tearDown,
  32. or whatever capability they make available in the parent class.
  33. PBSTestSuite offers the following:
  34. .. topic:: setUpclass:
  35. - Parse custom parameters that are passed in to the Class variable called 'param' (i.e. -p option to pbs_benchpress).
  36. The built-in parameters are:
  37. - servers: Colon-separated list of hostnames hosting a PBS server/scheduler.
  38. - server: The hostname on which the PBS Server/scheduler is running
  39. - moms: Colon-separated list of hostnames hosting a PBS MoMs.
  40. - mom: The hostname on which the PBS MoM is running
  41. - nomom: Colon-separated list of hostnames where not to expect MoM running.
  42. - comms: Colon-separated list of hostnames hosting a PBS Comms.
  43. - comm: The hostname on which the PBS Comm is running
  44. - client: For CLI mode only, name of the host on which the PBS client commands are to be run from.
  45. - clienthost: the hostnames to set in the MoM config file
  46. - mode: Mode of operation to PBS server. Can be either ‘cli’ or ‘api’.
  47. - conn_timeout: set a timeout in seconds after which a pbs_connect IFL call is refreshed (i.e., disconnected)
  48. - skip-setup: Bypasses setUp of PBSTestSuite (not custom ones)
  49. - skip-teardown: Bypasses tearDown of PBSTestSuite (not custom ones)
  50. - procinfo: Enables process monitoring thread, logged into ptl_proc_info test metrics.
  51. - procmon: Colon-separated process name to monitor. For example to monitor server, sched, and mom use procmon=pbs_server:pbs_sched:pbs_mom
  52. - procmon-freq: Sets a polling frequency for the process monitoring tool. Defaults to 10 seconds.
  53. - revert-to-defaults=<True|False>: if False, will not revert to defaults. Defaults to True.
  54. - revert-hooks=<True|False>: if False, do not revert hooks to defaults. Defaults to True. revert-to-defaults set to False overrides this setting.
  55. - del-hooks=<True|False>: If False, do not delete hooks. Defaults to False. revert-to-defaults set to False overrides this setting.
  56. - revert-queues=<True|False>: If False, do not revert queues to defaults. Defaults to True. revert-to-defaults set to False overrides this setting.
  57. - revert-resources=<True|False>: If False, do not revert resources to defaults. Defaults to True. revert-to-defaults set to False overrides this setting.
  58. - del-queues=<True|False>: If False, do not delete queues. Defaults to False. revert-to-defaults set to False overrides this setting.
  59. - del-vnodes=<True|False>: If False, do not delete vnodes on MoM instances. Defaults to True.
  60. - server-revert-to-defaults=<True|False>: if False, don’t revert Server to defaults
  61. - comm-revert-to-defaults=<True|False>: if False, don’t revert Comm to defaults
  62. - mom-revert-to-defaults=<True|False>: if False, don’t revert MoM to defaults
  63. - sched-revert-to-defaults=<True|False>: if False, don’t revert Scheduler to defaults
  64. - test-users: colon-separated list of users to use as test users. The users specified override the default users in the order in which they appear in the PBS_USERS list.
  65. - data-users: colon-separated list of data users.
  66. - oper-users: colon-separated list of operator users.
  67. - mgr-users: colon-separated list of manager users.
  68. - root-users: colon-separated list of root users.
  69. - build-users: colon-separated list of build users.
  70. - Check required users are available or not
  71. - Creates servers, moms, schedulers and comms object
  72. .. topic:: setUp:
  73. - Check that servers, schedulers, moms and comms services are up or not.
  74. - If any of services is down then starts that services.
  75. - Add the current user to the list of managers
  76. - Bring servers, schedulers, moms and comms configurations back to out-of-box defaults
  77. - Cleanup jobs and reservations
  78. - If no nodes are defined in the system, a single 8 cpu node is defined.
  79. - start process monitoring thread if process monitoring enabled
  80. .. topic:: tearDown:
  81. - If process monitoring is enabled the stop process monitoring thread and collect process metrics
  82. .. topic:: analyze_logs:
  83. - Analyzes all PBS daemons and accounting logs and collect logs metrics
  84. You can take advantage of PBSTestSuite's setUp and tearDown methods and extend
  85. their functionality by overriding the setUp and/or tearDown methods in your
  86. own class, for example
  87. ::
  88. class TestMyFix(PBSTestSuite):
  89. def setUp(self):
  90. PBSTestSuite.setUp(self)
  91. # create custom nodes, server/sched config, etc...
  92. For detailed test directory structure one can refer to below link:
  93. https://pbspro.atlassian.net/wiki/display/DG/PTL+Directory+Structure+and+Naming+Conventions
  94. Writing a test suite
  95. --------------------
  96. See ptl/tests/pbs_smoketest.py for some basic examples how to write test suite.
  97. Whenever possible consider making the test class inherit from PBSTestSuite, it
  98. is a generic setup and teardown class that delete all jobs and reservations,
  99. reverts PBS deamons configuration to defaults and ensures that there
  100. is at least one cpu to schedule work on.
  101. How to mark a test as skipped
  102. ------------------------------
  103. The unittest module in Python versions less than 2.7 do not support
  104. registering skipping tests. PTL offers a mechanism to skip test, it
  105. is however up to the test writer to ensure that a test is not run if
  106. it needs to be skipped.
  107. .. topic:: skipTest:
  108. Tests that inherit from PBSTestSuite inherit a method called ``skipTest`` that
  109. is used to skip tests, whenever a test is to be skipped, that method should be
  110. called and the test should return.
  111. .. topic:: checkModule:
  112. Tests that inherit from PBSTestSuite inherit a method called ``checkModule`` that
  113. is used to skip tests if require Python module is not installed.
  114. .. topic:: skipOnCray:
  115. Tests that inherit from PBSTestSuite inherit a method called ``skipOnCray`` that
  116. is used to skip tests on Cray platform.
  117. How to add a new attribute to the library
  118. -----------------------------------------
  119. This section is targeted to PBS developers who may be adding a new job, queue,
  120. server, or node attribute and need to write tests that depend on such a new
  121. attribute.
  122. PTL does not automatically generate mappings from API to CLI, so when adding
  123. new attributes, it is the responsibility of the test writer to define the
  124. attribute conversion in ptl/lib/pbs_api_to_cli.py. The new attribute must also
  125. be defined ptl/lib/pbs_ifl_mock.py so that the attribute name can be
  126. dereferenced if the SWIG wrapping was not performed.
  127. Here is an example, let's assume we are introducing a new job attribute called
  128. ATTR_geometry that maps to the string "job_geometry", in order to be able to
  129. set the attribute on a job, we need to define it in pbs_api_to_cli.py as:
  130. ATTR_geometry: "W job_geometry="
  131. and add it to ptl/lib/pbs_ifl_mock.py as:
  132. ATTR_geometry: "job_geometry".
  133. In order to get the API to take the new attribute into consideration,
  134. pbs_swigify must be rerun so that symbols from pbs_ifl.h are read in.