Wiki source code of Testing Concurreny
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | #### Problems | ||
| 2 | |||
| 3 | * Testing for concurrency is very difficult, which is why concurrency should be avoided in the first place. | ||
| 4 | * In general, this requires a lot of iteration, which makes it resource-intensive. | ||
| 5 | * The result is architecture dependent (OS, hardware), which introduces randomness and makes error detection unreliable. | ||
| 6 | |||
| 7 | #### Solution Approaches | ||
| 8 | |||
| 9 | * Monte Carlo Testing | ||
| 10 | * Write flexible, adaptive tests. | ||
| 11 | * Run them repeatedly on a test server, randomly varying the test settings. | ||
| 12 | * If something fails, the code is broken and the settings used should be logged. | ||
| 13 | * Do this early to gain tests ASAP for your test repertoire or CI server.Run tests on each platform over time to either confirm the correctness of the production code or to uncover bugs in the test code. | ||
| 14 | * Run the tests on a single machine, simulating application loads whenever possible. | ||
| 15 | * There are tools for testing thread-based code, such as ConTest. |