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 (2)

  1. Eivind says:

    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

  2. cellfish says:

    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…