2008 Advent Calendar December 7th

 

   1:      public class Advent7 : IDisposable
   2:      {
   3:          private IFileUtil m_file;
   4:          private const string m_content = "CONTENT";
   5:   
   6:          public Advent7()
   7:          {
   8:              m_file = new FileUtil("SomeFile.txt");
   9:              m_file.Create(m_content);
  10:          }
  11:   
  12:          public void Dispose()
  13:          {
  14:              m_file.Delete();
  15:          }
  16:   
  17:          [Fact]
  18:          public void TestReadOK()
  19:          {
  20:              string content = "";
  21:              Assert.DoesNotThrow(() => { content = m_file.Read(); });
  22:              Assert.Equal<string>(m_content, content);
  23:          }
  24:   
  25:          [Fact]
  26:          public void TestReadFails()
  27:          {
  28:              m_file.Readable = false;
  29:              Assert.Throws<AccessViolationException>(() => { m_file.Read(); });
  30:          }
  31:      }

Having the expected content in a constant member is pretty convenient but if the class grows and gets a lot of tests I'll have to scroll quite a bit to see the actual value. Personally I think you should have all the information needed for the test local in the test. Also I'm not a big fan of using the unit test framework "setup" mechanism since the reader of the test must know that the framework executes a certain setup-method. Even though that is probably true most of the time I think it is better to explicitly call the setup method and make it visible exactly how the test is set up.