Share via

Design Considerations for Stress Module Creation

  • Article

Consider the following suggestions when you design a test module for the Modular Stress Test.

  • Start simple. The usefulness of a test module depends on your ability to decipher its output. Start with a simple module that is easy to understand and debug. If the test module does not reveal bugs, add complexity later.
  • Do not hold resources. Usage of resources by a test module should not increase with the number of iterations run. Do not hold a system resource longer than necessary, because doing so makes it more difficult to track memory leaks. Do not wait until the testing process exists to free memory and empty caches, because the module may be required to run indefinitely.
  • Randomize the test. Generate complexity through combination rather than by adding complexity. Use the least code and most simple code that you can to cover the areas that you want to test.
  • Write solid code. Stress bugs take time to unravel. Minimize bugs in code for a test by following high standards in developing and thoroughly testing your modules before including them in the Modular Stress Test.
  • Write your test module with a specific scenario in mind. Do not randomly call APIs.
  • Be certain that you can always observe the state of your test. Check return values and error codes.
  • Do not rely on the state of the graphical user interface (GUI) to run your test. Do not use the keybd_event or mouse_event functions in your test.
  • Think multiple. The harness can run multiple copies of your module, which may cause test failures. For example, be careful not to use a window returned by the FindWindow function unless the window belongs to your process.

See Also

Custom Module Creation for the Modular Stress Test

 Last updated on Friday, October 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.