title: Unit testing - how to emulate a delay
body: <p>We've got a <em>large</em> C# solution with multiple APIs, SVCs and so on.
  Usual sort of enterprisy mess that you get after the same code has been worked on for years by multiple people.</p>
  
  <p>Anyway! We have an ability to call an external service and we have some unit tests in place that use a Moq like stub implementation of the services interface.</p>
  
  <p>It so happens that there can be a large delay in calling the external service and it's not anything that we can control (it's a GDS interface).</p>
  
  <p>We've been working on a way to streamline the user experience for this part of our platform.</p>
  
  <p>The problem is, the stub doesn't actually do much at all - and of course, is <em>lightening</em> fast, compared to the real thing.</p>
  
  <p>We want to introduce a random delay into one of the stubbed methods, that will cause the call to take between 10 and 20 seconds to complete.</p>
  
  <p>The naive approach is to do:</p>
  
  <pre><code>int sleepTimer = random.Next(10, 20);
  Thread.Sleep(sleepTimer * 1000);
  </code></pre>
  
  <p>But something about this gives me a bad feeling.
  What other ways do people have of solving this kind of scenario, or is Thread.Sleep actually Ok to use in this context ?</p>
  
  <p>Thanks for your time!</p>
  
  <p>-Russ</p>
  
  <p>Edit, To answer some of the comments:</p>
  
  <p>Basically, we don't want to call the live external service from our test suite, because it costs money and other business problems. </p>
  
  <p>However, we want to test that our new processes work well, even when there's a variable delay in this essential call to the external service.</p>
  
  <p>I would love to explain the exact process, but I'm not allowed to.</p>
  
  <p>But yeah, the summary is that our test needs to ensure that a long running call to an external service doesn't obstruct the rest of the flow; and we need to ensure that other tasks don't get into any kind of race conditions, as they depend on the result of this call.</p>
  
  <p>I agree that calling it a unit-test is somewhat incorrect now!</p>