The little “X” Button is meant to close, not to minimize!

One of my pet peeves is minimizing an application to tray. As you know there are three buttons in a standard Windows toolbar: Minimize, Maximize, Close. Minimize usually minimizes to the task bar. So there is no official button to minimize to tray. That leaves three usual options:

Have the minimize button minimize to tray
That seems to make most sense to me. If your application can minimize to tray, why would you want to alternatively minimize it to the taskbar as well? The downside of this is that for novice users it may be confusing (“Where did my app go?”).

Have a separate button to minimize to tray
Some applications have a new button for minimizing to tray:

Minimize to Tray

That seems to be a good balance between “do not confuse new users” and “offer a way to minimize to tray”. It’s just not consistent as different applications use different buttons, and some programmers do not seem to be able to do this properly, causing weird behavior (i.e. Classic Windows-Style Buttons in a Windows XP Screen).

Use the X Button
Minimize minimizes to taskbar, and the X minimizes to tray. To Exit, right click the tray icon and select “Exit”. That is braindead, sorry. The X Button is meant to close, and nothing else. Also, as the Systray (or Taskbar Notification Area) is usually set to auto-hide icons, closing an app is now a 4-Click Action: Click X, Click to expand Tray, Search Icon (and hope you find it before the Tray collapses again), Right Click Icon, Click Exit.

The reason why I am posting this is because TweetDeck just implemented that behavior, and I think it sucks. Really. If I click the X, i want it to close, and not find out later that it’s happily still taking my API Requests (Bad when working on a second PC) and using 126 Megabytes RAM.

X marks the spot to close, not to minimize.

Thank you.

The “rules” of TDD do not mean you shouldn’t do your tests properly

Okay, disclaimer first: I am not an expert in unit testing at all. I haven’t even used TDD in any bigger project yet. I am still learning all of this.

When I started to learn TDD, I encountered some “rules” that everyone seems to obey. But it looks like sometimes they are taken too strict or are just not properly understood and therefore applied incorrectly. Here are some of these “rules” and my understanding of them.

Don’t test Getters/Setters
This rule means that you don’t need Unit tests for your simple Getters/Setters unless they have logic. Let’s look at a class and unit tests:

class MyPOCO
{
    public string SimpleString { get; set; }
}

[TestFixture]
public class UnitTests
{
    [Test]
    public void UnneccessaryTest()
    {
        var testclass = new MyPOCO();
        testclass.SimpleString = "Test String";
        Assert.AreEqual("Test String", testclass.SimpleString);
    }
}

So we have a simple POCO that holds a string. However, as the string has no logic whatsoever, the unit test is unnecessary – we can safely assume that this will never break. It’s 100% .net Framework stuff here, so if this unit test ever fails, the world is likely to end a minute or two later. So no need to test this string Getter/Setter. But you still want to test it if it comes from a Business Object.

For example, this here warrants a unit test:

public static class MyBusinessClass
{
    public static MyPOCO GetSomething()
    {
        return new MyPOCO() {SimpleString = "data"};
    }
}

[TestFixture]
public class UnitTests
{
    [Test]
    public void TestBusinessClass()
    {
        Assert.AreEqual("data",MyBusinessClass.GetSomething().SimpleString);
    }
}

As you see, we test the Getter of SimpleString. But in reality, we are testing that MyBusinessClass returns the expected value. That does seem logical and natural, but I’ve seen people not testing the return values because of the “No need to test Getters” rule. Again: This is about testing the Getter of SimpleString, this is testing the return value of MyBusinessClass.

Unit Tests are independent from each other
This rule says that Unit tests should not impact each other and should make no assumptions about other tests. For example, this is bad:

public static class MyVictim
{
    public static int SomeInt { get; set; }
}

[TestFixture]
public class BadUnitTests
{
    [Test]
    public void TestOne()
    {
        // Imagine a lot of complicated business logic that would
        // justify this test, but the important thing is that we
        // set MyVictim.SomeInt to a known value.
        Assert.DoesNotThrow(() => MyVictim.SomeInt = 150);
    }

    [Test]
    public void TestTwo()
    {
        Assert.AreEqual(150, MyVictim.SomeInt);
    }
}

As you see, TestOne modifies MyVictom.SomeInt to set it to 150. TestTwo checks that MyVictim.SomeInt really is 150. This is assuming that these two tests run in order. But if the test runner decides to run TestTwo first or to run them in parallel, it will fail (or in case of parallel testing it sometimes will and sometimes will not). But that does not mean that you should be copy/pasting your code in your Unit Tests! Independent Tests does not mean this:

public class MyClassUnderTest
{
    private int _someInt;
    private bool _someBool;

    public MyClassUnderTest(string param1, string param2, int param3, long param4, bool param5)
    {
        _someInt = param3;
        _someBool = param5;
    }

    public void Initialize(string something)
    {
    }

    public bool BusinessFunctionOne()
    {
        return _someBool;
    }

    public int BusinessFunctionTwo()
    {
        return _someInt*2;
    }
}

[TestFixture]
public class CopyPastedUnitTests
{
    [Test]
    public void TestOne()
    {
        var testclass = new MyClassUnderTest("1", "x", 10, 100, true);
        testclass.Initialize("bla");
        Assert.IsTrue(testclass.BusinessFunctionOne());
    }

    [Test]
    public void TestTwo()
    {
        var testclass = new MyClassUnderTest("1", "x", 10, 100, true);
        testclass.Initialize("bla");
        Assert.AreEqual(20,testclass.BusinessFunctionTwo());
    }
}

As you see, the Initialization Code of MyClassUnderTest is copy/pasted between the two unit tests. Now try change a parameter in the constructor and see all your tests break at once. Also note how the test class needs a separate Initialize-method to be called, so you need two lines to spin it up.

You can still keep OO Principles/DRY without having to make your tests dependent on each other! For example, you can check if your unit test framework has a Setup function that is called for every test. That allows you to move out shared source into a common function:

[TestFixture]
public class CopyPastedUnitTests
{
    private MyClassUnderTest testclass;

    [SetUp]
    public void InitializeTestclass()
    {
        testclass = new MyClassUnderTest("1", "x", 10, 100, true);
        testclass.Initialize("bla");   
    }

    [Test]
    public void TestOne()
    {
        Assert.IsTrue(testclass.BusinessFunctionOne());
    }

    [Test]
    public void TestTwo()
    {
        Assert.AreEqual(20,testclass.BusinessFunctionTwo());
    }

    [Test]
    public void TestThree()
    {
        var anothertestclass = new MyClassUnderTest("1", "x", 10, 100, false);
        anothertestclass.Initialize("x");
        Assert.IsFalse(anothertestclass.BusinessFunctionOne());
    }
}

This will create a new TestClass for each test, but that is using a common function. TestThree can still spin up it’s own if it does need a different version. You could also create a private method within the Unit Test class that takes some parameters and returns a MyTestClass that the Tests can then use.

Bottom Line: Making the tests independent from each other does not mean you can’t or shouldn’t use the DRY principle. Test Classes are still normal classes that can have non-test variables and helper functions.

Unit Test code is still code and it should still be taken seriously. Don’t let your unit tests become an unmaintanable mess. Always make sure that you are checking the right things with the least amount of code.

My thoughts on the CodePlex Foundation

Okay, so yesterday Microsoft announced the creation of the CodePlex Foundation, a “non-profit foundation formed with the mission of enabling the exchange of code and understanding among software companies and open source communities”. Well, that sounds very vague, and indeed it is for the moment:

We don’t have it all figured out yet. We know that commercial software developers are under-represented on open source projects. We know that commercial software companies face very specific challenges in determining how to engage with open source communities. We know that there are misunderstandings on both sides. Our aim is to advance the IT industry for both commercial software companies and open source communities by helping to meet these challenges.

Meeting these challenges is a collaborative process. We want your participation.

Okay, so here are my thoughts. At first, it seems a bit superflous to have yet another open source foundation. After all, are the Free Software Foundation or the Open Source Initiative not already doing exactly this? And isn’t Microsoft one of the least likely companies to be involved in Open Source? Yes and No.

Let me start with Microsoft as a company. They have had their fair share of anti-OSS Crusades, especially against Linux (Halloween Papers anyone?). Also their stance towards software patents goes quite a bit against the OSS thought (and has recently backfired heavily). Their VFAT patent is another brick in the wall that seems to separate Microsoft from Open Source Software.

However, Microsoft is big. And when I say big then I mean that they hold their company meetings in a football stadium, holding 25000+ people. They have more departments than most other companies have employees. And naturally, there are a lot of different directions within Microsoft. In the last few years, the Developer Tools section of Microsoft started to become more open. WiX was the first product to be licensed as Open Source, and many more would follow, especially such important ones around ASP.net. Microsoft also launched their own Source Code portal – CodePlex – in 2006 which may still have a few rough edges, but works really well for me. And People like Sara Ford are really pushing this forward.

You can argue whether or not this is really open source, as Microsoft does not really seem to accept patches. There are some legal issues around this (i.e. what if you contribute code you have written at work to Microsoft’s Open Source project, but six months later your company finds this out and demands removal of your code from the project because you never had the right to contribute it? Most Open Source projects can fall into that trap, but if you’re high profile like Microsoft you certainly want to be careful.) and I found that it isn’t that different from many other projects. Try contributing some code to the Linux Kernel or the Apache Web Server, who are also having high requirements and a QA/Testing cycle.

I think the DevTools section really understood the value of Open Source, also in terms of acceptance. For example, Classic ASP.net sometimes required using Reflector to understand some of the Magic that is going on, for example around Global.asax. ASP.net MVC is now Open Source, which doesn’t mean anything for possibly 95% of all users (number made up), but for the 5% that really need to understand or change some inner part, it’s a blessing. It’s also a sign of the competition coming from Ruby on Rails, Grails or Django.

So from my perspective as a C# developer, Microsoft and Open Source are not two opposite extremes, and the CodePlex Foundation doesn’t seem to be like something aimed at destroying Open Source, because I see it being led by the people who are OSS people at Microsoft.

That leaves the question: Why another OSS Foundation? Or more precisely: What can CodePlex Foundation add?

Well, in my opinion, it’s the Microsoft name behind it. Of course they say they are independent and stuff, but even if they are, I think that the Microsoft name is huge. I have to say that I am blessed to work in a company that has no issues using Open Source software, but I also know many companies who do not understand the concept. Many companies still believe that if you use OSS Software (even just downloading an executable and using it), you have to put your entire software under open source. Also, many companies still believe that open source software is buggy, insecure and written by socialist left-wing communist terrorists. Well, some certainly is, but it’s not like there isn’t some horribly bad commercial software as well.

The FSF and OSI Images are closely tied to all of this. FSF, OSI, Linux, Open Source – all a bunch of Hippies, opposite to real companies like IBM, Oracle, Microsoft et al. Luckily, this wrong perception is gradually changing, but the fear still stays. But now, having a behemoth like Microsoft suddenly standing behind an Open Source Foundation could be a big enabler. You know the saying “No one ever got fired for choosing Microsoft?” It’s usually used in the context of choosing some software that the company is unfamiliar with, so usually they play safe and choose the big name.

That is one win that CodePlex Foundation could bring: Raise the awareness that Open Source may be high quality software backed by big companies. In the mid-term, this could eliminate some of the mentioned “misunderstandings on both sides” mentioned in their mission statement.

So, CodePlex Foundation wants to know what they can do to help? Well, the biggest problem with Open Source is that there is a gazillion of licenses. There is the GPL, the LGPL, the BSD License, the MPL or the MS-PL. The OSI currently lists 65 different open source licenses. Sixty-Five. How is anyone able to know which ones are compatible? Can I mix MPL with BSD and MS-PL? What about the Apache License?

Also, some of them are really restrictive, like the GPL. And I think it’s the GPL that causes all this fear around Open Source because companies still think Open Source = GPL. Now, don’t get me wrong: I think the GPL is doing a great job to make sure that code stays open. But it’s also a big blocker because companies naturally feel their secrets threatened if they use anything that even looks like GPL. And as the GPL Violations show, many companies learn this the hard way. But there are also big misunderstandings around this. For example, you can freely use GPL code in a web application without having to provide the source code to it. That is, unless it’s Affero GPL or AGPL, which was created specifically to close this loop hole. On the other hand, you can almost always safely use LGPL code because this only requires modifications to itself to be released again under LGPL, but it’s not viral and does not affect your application.

The other extreme to the GPL is BSD or MS-PL code which basically says “Do what you want, but credit us”. But I still don’t know what the difference between BSD and MS-PL really is, except something around patents. That leaves me with the question: Can I safely mix BSD and MS-PL code?

In my opinion, this is the #1 task that needs to be resolved in the Open Source world, and the CodePlex Foundation with it’s aim at corporate entities should (or even: would have to) make this easier. I’m envisioning a very graphical site that essentially says “if you have this license, these are your duties”, a bit similar to how Creative Commons presents their licenses. Or what about a Mix-And-Match page where I can say “I have code under LGPL and under MS-PL. Can I mix them? Do I have to take any precautions? If they are incompatible, how can I still mix them? (i.e. can I just put the GPL Code in a different project and use it from a Non-GPL application using public interfaces?)”

CodePlex Foundation, please give us something “Executive-Friendly” that can be used to convince reluctant decision-makers. This would be my #1 wish.

The Art of Unit Testing Book Review

The Art of Unit Testing Cover
I have a few confessions to make. First, I still read books, although for technical books I’ve switched to electronic formats instead of dead trees thanks to my long-running Netbook. But I just prefer the format of concise and complete information logically grouped together. Blogs and sites like StackOverflow are nice for specific topics, but even article series in blogs often cannot compete with the layout of books.

My second confession is that I do not practice Unit testing. Sure, I’ve spent some time reading about Unit Testing and played around with both NUnit and xUnit.net, but I never made tests that were more complicated than calling a function and asserting on the result. Mainly because I never understood more complicated concepts, I was never sure about the difference between unit and integration testing, and I thought that Mock Framework is black arcane magic.

Mainly because that’s what most blog articles in the internet tell you. There are plenty of articles among the lines of “Assert(4,Add(2,2))” but that’s about it. There are plenty of other articles about Unit testing, but I did not find any “Tutorial” that goes all the way from a simple assert to a full-blown solution involving stubs, a mock object and a database.

Until two weeks ago. I was browsing Manning for another book (C# in Depth, Second Edition by Jon Skeet) and saw Roy Osherove’s The Art Of Unit Testing. I was looking through the reviews at Amazon and decided to buy it – and I am absolutely thrilled by it!

First, it’s a very practical book. Roy doesn’t have many long-winded explanations, but instead he briefly introduces a concept, then presents some (C#) code, and then explains a bit more. This is great, because it allows the reader to take baby-steps. He starts writing Test Code without a Unit Test Framework to introduce the concept, but then quickly switches to NUnit throughout the rest of the book. That’s a nice little touch because for people who have absolutely no idea what problem Unit Test frameworks solve, this should explain it.

It then goes on to some more complicated (but more real-world) scenarios, i.e. involving testing a function that normally calls the file system. Again, Roy first illustrates how you could do it entirely manually (briefly covering dependency injection) before he moves on using a Framework. Only after laying all the groundwork he starts involving a Mock Framework – Rhino.Mocks – and starts with relatively simple scenarios as well.

This may sound like a “How to use NUnit and Rhino.Mocks” book, but it isn’t. As said, Roy explains all the concepts and starts building completely manual solutions at first, which means that all concepts should be known and you should easily be able to adapt it to whatever Unit Test and Mock Frameworks you use.

And that’s the beauty of this book: It’s about concepts, explained through practical examples. If you know what a Mock is and how it’s different from a Stub, if you know the difference between Unit and Integration testing, if you know how to approach any given problem, it does not matter what framework you’re using.

The little icing on the cake is the chapter about “Working with legacy code” which explains how you can add unit testing into existing applications, which can often be overwhelming if the legacy application is old, big, badly documented and mainly held together with duct tape and prayers, which means that no one wants to touch it.

Now, no good review is complete without listing some negative points. (Side note: Any review that is absolutely and 100% positive is not a review, but a marketing publication and therefore useless): Mainly, I would have wished a bit more about unit testing user interfaces. Neither ASP.net nor WinForms nor WPF is covered, although there is a whole Appendix at least listing additional tools and frameworks. I think there would be some room in a second edition to make a mostly complete Step-By-Step-Tutorial even more complete.

Conclusion: It’s great that Roy Osherove is the author of this book, because he is not just an expert on one specific framework, but he rather knows about the whole concepts and foundations of unit testing. That results in a well-balanced and complete book. He uses NUnit and Rhino.Mocks only as a “device” to explain the concepts instead of making them the “stars” of this book.

I can wholeheartedly recommend it.