Design Considerations for Stress Module Creation

Other versions of this page are also available for the following:

• Windows Embedded CE 6.0 R3

8/27/2008

Consider the following suggestions when you design a test module for the Windows Embedded CE Stress tool:

• Start simple.
  The usefulness of a test module depends on your ability to decipher its output. Start with a simple test module that is easy to understand and debug. If the test module does not reveal bugs, add complexity later.
• Do not hold resources.
  Use 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 test module might be required to run indefinitely.
• Randomize the test.
  Generate complexity through combination rather than by adding complexity. Use the least and simplest 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 test modules before including them in the Windows Embedded CE Stress tool.
• Write your test module with a specific scenario in mind.
  Do not randomly call APIs.
• 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.
  Functions such as the keybd_event function or mouse_event function rely on the state of the GUI.
• Consider that the harness can run multiple copies of your test module, which might cause test failures.
  For example, using a window returned by the FindWindow function might cause a failure unless the window belongs to your process.

See Also

Other Resources

Custom Module Creation for the Windows Embedded CE Stress Tool