title: Unit testing concurrent software - what do you do?
body: <p>As software gets more and more concurrent, how do you handle testing <em>the core behaviour of the type</em> with your unit tests (not the parallel behaviour, just the core behaviour)?</p>
  
  <p>In the good old days, you had a type, you called it, and you checked either what it returned and/or what other things it called.</p>
  
  <p>Nowadays, you call a method and the actual work gets scheduled to run on the next available thread; you don't know when it'll actually start and call the other things - and what's more, those other things could be concurrent too.</p>
  
  <p>How do you deal with this? Do you abstract/inject the concurrent scheduler (e.g. abstract the Task Parallel Library and provide a fake/mock in the unit tests)?</p>
  
  <p>What resources have you come across that helped you?</p>
  
  <hr>
  
  <p><strong>Edit</strong></p>
  
  <p>I've edited the question to emphasise testing the normal behaviour of the type (ignoring whatever parallel mechanism is used to take advantage of multi-core, e.g. the TPL)</p>
  
  <hr>