Multithreading a unit test
To test for concurrency issues, I want the same method on two different threads at the same time to use a unit test. Actually I probably want to call the same method on multiple threads at the same time.
I am using Microsoft built-in tester for VS2008.
My thoughts are that I will lock the object and then synchronously set up each of the threads, which will immediately wait for the lock, and then release the lock, which will allow all threads to access the shared resources and test the code's ability to handle multiple threads correctly.
Has anyone done this before? Am I taking a sane approach here?
source to share
I've done this before, and while the results aren't always reproducible, they can highlight problems or bugs in your code.
I don't use Microsoft unit testing for this, but I prefer MbUnit , which has a ThreadedRepeat attribute that lets you specify how many themes you want to run. This makes the task of multithreading easier, just write the test and add the attribute.
source to share
If you are using unit tests to test multi-threaded code, you are probably wrong.
First, you have no guarantee that both methods will run at the same time; this means that your tests do not guarantee that your code will work.
You can probably test if your method works well in a multithreaded environment by inserting sleep commands, but this is too intrusive for unit tests; this is actually a proof of concept, not something I will leave as a unit test after I am sure that a piece of code works as intended.
Multi-threaded tests are fine in and of themselves to speed up unit testing when unit tests take a long time, but unit testing is very important for testing small, isolated methods.
What you might think is stress testing, but it is done "from the outside" as opposed to "from the inside" like unit tests. This means that you write the client again on your server and run it thousands of times from multiple computers, checking the entire system, not a single isolated method. There are two main benefits of stress testing. Firstly, stress testing is used to pinpoint the type of defect that occurs once every hundred runs in a real-time situation, and secondly, since they are done "externally", they better reproduce how flows will permeate your application.
The unit tests in my example are not as bad for testing multi-threaded code as running your code through the debugger - while one thread is waiting for you to start the next step, another thread will time out and you will never have real -life ...
To summarize, not everything should be unit tested; proof of concept tests is a good way to ensure that your thread-safe collection is truly thread-safe, and stress testing is great for finding bugs in multithreaded code.
source to share
On a unit test, I think this is suboptimal as Kibby points out that it may or may not be done. You will need to run this hundreds or thousands of times, and even then you may never run into an error, even if a race condition exists.
If you are trying to ensure there are no deadlocks, you can look at the typemock racer: http://www.typemock.com/learn_about_typemock_racer.html I have no experience with him, but he looks like he can spot a lot of dead ends.
source to share