Testing Against Non-Determinism

Although computers tend to be rather deterministic in nature, you will sometimes have to deal with concepts that are de-facto non-deterministic. These include, but are not limited to:

• Random numbers. These are typically generated by a random number generator (such as System.Random).
• Guids. These are generated by a complex algorithm that utilizes the current system time, system properties, etc. Although not a pseudo-random number in itself (it's not designed to follow any particular stochastic distribution), it's virtually impossible to predict the value of a new Guid before its creation.
• Current system time. You never know exactly when your code executes.

When testing code, non-determinism is undesirable, since one of the main principles of automated testing is that test results are reproducable; if you run a unit test suite a number of times without changing the code, the outcomes should all be identical. If your test target contains non-deterministic logic, you may find this principle difficult to uphold. In a small series of postings, I'll provide a few pointers on how to deal with this challenge.

Each post will cover a particular type of non-determinism, and provide examples on how to handle it in unit tests:

1. Testing Against Randomness
2. Testing Against Guids
3. Testing Against The Current Time
4. Testing Against The Passage of Time

Comments

• Anonymous
  May 11, 2007
  This is the first in a small series of posts about testing against non-determinism. In this installation,

• Anonymous
  May 12, 2007
  This is the second in a small series of posts about testing against non-determinism. In this installation,

• Anonymous
  May 12, 2007
  This is the third in a small series of posts about testing against non-determinism. In this installation,

• Anonymous
  May 12, 2007
  This is the third in a small series of posts about testing against non-determinism. In this installation,