Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

2008 Advent Calendar December 12th

Change of Address
This blog has moved to blog.cellfish.se.

2008 Advent Calendar December 12th

  • Comments 2

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?

  • 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

  • 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...

Page 1 of 1 (2 items)