2008 Advent Calendar December 16th

 

   1:      public class Advent16
   2:      {
   3:          private FileUtilWithDelete SetUp(string content, bool readable)
   4:          {
   5:              FileUtilWithDelete file = new FileUtilWithDelete("SomeFile.txt");
   6:              file.Create(content);
   7:              file.Readable = readable;
   8:              return file;
   9:          }
  10:   
  11:          [Fact]
  12:          public void TestReadReadableFile()
  13:          {
  14:              using (FileUtilWithDelete file = SetUp("CONTENT", true))
  15:              {
  16:                  string content = file.Read();
  17:                  Assert.Equal<string>("CONTENT", content);
  18:              }
  19:          }
  20:   
  21:          [Fact]
  22:          public void TestReadUnreadableFile()
  23:          {
  24:              using (FileUtilWithDelete file = SetUp("SHOULD NOT BE ABLE TO READ THIS", false))
  25:              {
  26:                  Assert.Throws<AccessViolationException>(() => { file.Read(); });
  27:              }
  28:          }
  29:      }

This test code starts to look pretty decent, don't you think? Well I think it is time to address the naming of the tests again. Even though I know the circumstances I'm testing I think the name should include something about the expected result also. And "Failing" that we used before is not really a good expected result (but it is better than nothing which is the case now).