Archives

Archives / 2004 / April

  • Sometimes it's Better to Check Even Really Obvious Dialog Defaults

    No Comments

    If you only have a C# project file named e.g. "foobar.csproj" in a directory, opening it in the Visual Studio IDE (VS.Net 2003) will create a solution file for you. Either when saving or exiting you'll be asked for the file name, with the default name being e.g. "foobar.sln".

     

    After being asked for solution file names over and over again, I never looked at the default name again - I simply hit Ok as soon as the dialog popped up.

     

    Tip: You shouldn't do this if your project filename contains a dot. Because for a project named e.g. "foo.bar.csproj", the default name of the automatically generated solution file is "foo.sln", not "foo.bar.sln" as one would expect. For "X.Y.Z.csproj" the default name is "X.Y.sln", for "A.B.C.D.csproj" the default name is "A.B.C.sln", and so on.

    In contrast, if you create a new project from scratch, the solution name is the same as the project name, even if the project name contains a dot.

     

  • Don't Underestimate the Benefits of "Trivial" Unit Tests

    4 Comments

    Take a look at the following example of a trivial unit test for a property. Imagine a class MyClass with a property Description:

    public class MyClass
    {
        ...
        private string m_strDescription;
        public string Description
        {
            get { return m_strDescription; }
            set { m_strDescription=value; }
        }
        ...
    }

    And here's the accompanying unit test:

        ...
        [ Test ]
        public void DescriptionTest()
        {
            MyClass obj=new MyClass();
            obj.Description="Hello World";
            Assert.AreEqual("Hello World", obj.Description);
        }
        ...

    Question: What's the benefit of such a trivial test? Is it actually worth the time spent for writing it?

    As I have learned over and over again in the past months, the answer is YES. First of all, knowing that the property is working correctly is better than being "really, really sure". There may not be a huge difference in the moment you write the code, but think again a couple weeks and dozens or hundreds of classes later. Maybe you change the way the property value is stored, e.g. something like this:

     

        public string Description
        {
            get { return m_objDataStorage.Items["Description"]; }
            set { m_objDataStorage.Items["Description"]=value; }
        }

    Without the unit test, you would test the new implementation once, then forget about it. Now another couple of weeks later some minor change in the storage code breaks this implementation (causing the getter to return a wrong value). If the class and its property is buried under layers and layers of code, you can spend a lot of time searching for this bug. With a unit test, the test simply fails, giving you a pretty good idea of what's wrong.

     

    Of course, this is just the success story... don't forget about the many, many properties that stay exactly the way they were written. The tests for these may give the warm, fuzzy feeling of doing the "right thing", but from a sceptic's point of view, they are a waste of time. One could try to save time by not writing a test until a property's code is more complicated than a simple access to a private member variable, but ask yourself how likely it is that this test will be written if either a) you are under pressure, or b) somebody else changes the code (did I just hear someone say "yeah, right"? ;-). My advice is to stop worrying about wasted time and to simply think in terms of statistics. One really nasty bug found easily can save enough time to write a lot of "unnecessary" tests.

     

    As already mentioned, my personal experience with "trivial" unit tests for properties has been pretty good. Besides the obvious benefits when refactoring, every couple of weeks a completely unexpected bug gets caught (typos and copy/paste- or search/replace mistakes that somehow get past the compiler).

  • XML Documentation Comment Tooltips (Wouldn't it be cool, part 5)

    No Comments

    While I do write XML documentation comments for all my code (except throwaway stuff), I rarely actually read e.g. the CHM file generated by NDoc. But as we all know, a cool feature of VS.Net is that the content of XML documentation comments is used in various situations to display tooltips, which may look something like this:

    Unfortunately, if users of my code (i.e. either other developers, or me after a couple of weeks) read only the tooltips, they may miss valuable information, e.g. descriptions of return values or remarks. The problem is that there's no way to tell whether additional information is available, so one usually assumes that it is not -- especially if you have looked a couple of times into a CHM documentation file for a specific topic only to be disappointed.

    So I think it would be a cool feature if tooltips could display more information, maybe like this:

    Of course the texts should be truncated to a reasonable maximum size (in order to avoid something like the sometimes screen-filling tooltips of the NUnit GUI ;-).

    Other "Wouldn't it be cool" posts: