title: Standard .Net TDD Memory Test
body: <p>Is it useful to write a standardised TDD [Test] method that would expose common memory issues ?</p>
  
  <p>The set of tests could be easily, quickly applied to a method and would red-fail 'classic' .NET memory issues but would  green-pass the classic solutions. </p>
  
  <p>For example common memory issues could be : too much relocation by the garbage collector
  ; allocating too much ;  too many garbage collections ( classic example prefer StringBuilder over string reallocs );  holding on to memory for too long (classic example call dispose and do not reling on finalizers );  objects inappropriately reaching g1, g2, LOH ; little leaks that add up to something significant over time, … and others.</p>
  
  <p>Perhaps the code could look something like this …</p>
  
  <pre><code>[Test]
  public void Verify_MyMethodUnderTest_Is_Unlikely_To_Have_Common_Memory_Problem()
  {
  
  //-Setup
  var ExpectationToleranceA = ...
  var ExpectationToleranceB = ...
  ...
  
  //-Execute
  var MeasurementA = MyClassUnderTest.MyMethodUnderTest( dependancyA ) ; 
  var MeasurementB = MyClassUnderTest.MyMethodUnderTest( dependancyB ) ; 
  …
  
  //-Verfiy
  Assert.That(  MeasurementA  , Is.WithinTolerance( ExpectationToleranceA  ) ) ;
  Assert.That(  MeasurementB  , Is.WithinTolerance( ExpectationToleranceB  ) ) ;
  
  }
  </code></pre>
  
  <p>There are other posts on memory pressure issues, but the idea here is to be able to quickly point a standard test at a method and the test would red-fail at common/classic memory pressure issues but green-pass the common solutions. A developer may then be pointed to review failing code and possibly fix the leak, change the tolerances or even remove the TDD memory pressure test.</p>
  
  <p>does this idea have legs?</p>
  
  <p>There is a related question here for C++ app, <a href="https://stackoverflow.com/questions/169058/memory-leak-detection-while-running-unit-tests">Memory leak detection while running unit tests</a>,  which is a similar question but not quite the same thing.  Twk's question is pointing to looking at memory after all the test have run ...</p>
  
  <p>My idea here is for .NET to 
  1) unit test each method for common memory issues 
  2) fail the classic memory issues 
  3) pass the classic fixes to classic common memory issues 
  4) be able to quickly throw a quick standard test at a function to see whether it exhibits classic symptoms 
  5) be able to upgrade the Standard TDD .Net Memory Pressure Test applied in the unit test.  This implies a refactor of the above code so that upgrades to the standard test will change upgrade the  memory tests applied throughout the Nunit test suite for a project.</p>
  
  <p>(p.s. I know there is no Is.WithinTolerance call but I was just demonstrating an idea. )
  cheers ...</p>