2008 Advent Calendar December 12th

 

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

Since the setup-method is called explicitly, why not have several setup-methods for different kinds of setup?

Comments

• Anonymous
  December 15, 2008
  What is your opinion on these naming alternatives: 1-Not include "Test" in the fact method (implied by [Fact] anyway) 2-Describe specified outcome (can/cannot read) rather than action (read) Examples: TestReadReadableFile -> CanReadReadableFile TestReadUnreadableFile -> CannotReadUnreadableFile

• Anonymous
  December 15, 2008
  Well, if you follow this series of tests to the end I guess you'll get the answer... :-) And the answer is; I think you should name your methods what they do. I personally do not name methods something like "TestXXX". Your proposed alternatives are much better I think. But I will not tell you what I would name the methods just yet. That is what the December 18th post is all about...