I totally disagree. Running the same test on the same machine will not do much but running integration tests and running on different environments you will surface some of the racing conditions (works especially for desktop apps)

Another great way to iron out race conditions and the such is to perform load testing - works especially for services and websites. The extra load will force the threat scheduler to adopt different patters in allocating threads. For database level deadlocks you can monitor performance counters that relate to this. For the service level - well you'll most likely get some exceptions that are very difficult to reproduce - I recommend taking a look at a historical debugger such as IntelliTrace if you are in the .net world.

Also, check out a research product from Microsoft called Chess - it essentially changes the threat scheduler of a process on every test run - that should trigger quite a few of the race conditions.

http://research.microsoft.com/en-us/projects/chess/

I totally disagree. Running the same test on the same machine will not do much but running integration tests and running on different environments you will surface some of the racing conditions (works especially for desktop apps)

Another great way to iron out race conditions and the such is to perform load testing - works especially for services and websites. The extra load will force the threat scheduler to adopt different patters in allocating threads. For database level deadlocks you can monitor performance counters that relate to this. For the service level - well you'll most likely get some exceptions that are very difficult to reproduce - I recommend taking a look at a historical debugger such as IntelliTrace if you are in the .net world.

Also, check out a research product from Microsoft called Chess - it essentially changes the thread scheduler of a process on every test run - that should trigger quite a few of the race conditions.

http://research.microsoft.com/en-us/projects/chess/

I totally disagree. Running the same test on the same machine will not do much but running integration tests and running on different enviroments you will surface some of the racing conditions.

Also, check out a research product from Microsoft called Chess - it essentially changes the threat scheduler of a process on every test run - that should trigger quite a few of the race conditions.

http://research.microsoft.com/en-us/projects/chess/

I totally disagree. Running the same test on the same machine will not do much but running integration tests and running on different environments you will surface some of the racing conditions (works especially for desktop apps)

Another great way to iron out race conditions and the such is to perform load testing - works especially for services and websites. The extra load will force the threat scheduler to adopt different patters in allocating threads. For database level deadlocks you can monitor performance counters that relate to this. For the service level - well you'll most likely get some exceptions that are very difficult to reproduce - I recommend taking a look at a historical debugger such as IntelliTrace if you are in the .net world.

Also, check out a research product from Microsoft called Chess - it essentially changes the threat scheduler of a process on every test run - that should trigger quite a few of the race conditions.

http://research.microsoft.com/en-us/projects/chess/