Testing Multithreaded Code
It’s hard enough to write code that works as expected. That’s one reason to write unit tests. It’s dramatically harder to write concurrent code that works.
In one sense, testing application code that requires concurrent processing is technically out of the realm of unit testing. It’s better classified as integration testing: you’re verifying that you can integrate the notion of your application-specific logic with the ability to execute portions of it concurrently.
Tests for threaded code tend to be slower—and we don’t like slower tests when unit testing—because you must expand the scope of execution time to ensure that you have no concurrency issues. Threading defects sometimes sneakily lie in wait, surfacing long ...