Thursday, July 29, 2010

Why Microsoft Makes Bad Programmers

After the LIDNUG presentation, we stayed online to discuss unit testing experiences. A couple of things stayed with me from that talk. One: we’re (we developers) are obsessed with tooling and technology (you didn’t expect hard news here, right?). Our main focus should be about solving the business problem first. But, us geeks, we like to know more about the how, rather than the why.

The second is that Microsoft, by providing better and better VS experience,  and a couple of great technologies, created less and less gifted programmers, and more professional debuggers. And I mean the people, not the tools.

Microsoft is not the only culprit (hey, it’s true around the software world). With our obsession for tools and technology (which MS provided), we needed better tools for getting ourselves out of more and more messes. So MS obliged, and gave us better debuggers, and for that we became proficient at excavating software problems.  

If we chose the road less travelled, we would be working on eliminating bugs before they happen. This of course falls under the jurisdiction of better programming.

So the next time someone asks: why isn’t TDD catching on? You can blame Microsoft, or their tools, or the software industry in general. Tell’em I said so.

What can you do? Now, that’s your responsibility and what makes you a professional. 

Think about your code before you write it. Make sure it works. Review it. Think about where the bugs can hide, and leave traps for them, to catch them when they rear their ugly head.

Program better.

Gil Zilberfeld

Tuesday, July 27, 2010

Secrets of an online presentation

Last week I gave my “unit testing in the wild” presentation on LIDNUG. It was nice, and once the recording is up I’ll get all the info. But I wanted to talk about the experience.

First of all: people, I’ve hit the jackpot. I’ve hit on one of the best ways to extract gold out of lead. Almost. I’ve figured how to make time to prepare for the presentation: Traffic.

Ok, I’m sure people did that before cars, like riding their horse and carriage and practicing their PowerPoint pitch. They probably had more time. But for the 21st century,  in which I spend 1.5-2 hrs a day in commute – this is no longer podcast listening time – it’s talk to yourself time. Sure you look weird, but it’s great practice time. Repeat, repeat, and try not to bump into the car in front.

The how-to: I print my slides with notes, and start talking to the steering wheel. Basically simple. Allow yourself to get excited, it really helps.

Back to the presentation. Man, it’s hard getting no feedback. Online is usually bad enough when you have to rely on vocal feedback, when people talk to you (this happens when I do an online demo). But an online broadcast- no online feedback at all.

Since you don’t know how you’re doing without feedback, you need to control and modify what you’re doing, or go with the flow and do your best. Since I find doing 2 things at a time quite problematic, I go with the flow.

Finally, I’ll go to the beginning – selecting the topic. I went through a couple of thinking cycles here. I could do basic unit testing stuff, or advanced. I could also do a lap around the Typemock tools.

I finally decided to look at unit  testing differently – solving different unit testing problems. This was no longer about the tools (which of course were presented), but about: hey, you may have bumped into this once, next time, here’s how you go around it.

If you attended, give me a shoutout, and give me feedback. If not, I hope the recording will be up soon so you can do that as well.

Gil Zilberfeld

Monday, July 19, 2010

Presenting at LIDNUG this Thursday

I’ll be presenting on the next LIDNUG’s online presentation, Thursday, July 22nd, 11:00AM to 12:30PM PDT/PST (GMT-8). My presentation will be about “Unit testing in the wild”. I’ll show how to test real code, that happens to be in real life.

Expect the unexpected. Ok, and code examples in different technologies, like SharePoint, WCF and ASP.Net, with the help of Typemock tools.

Come one, come all (I prefer all), it’s free. You can RSVP and read more about it in this page.

Gil Zilberfeld (that cute guy on the right)

Wednesday, July 7, 2010

Battle of the framework: Testing a Webpart

Time to see the difference between Moles and Isolator code. Let’s start with the code under test (a webpart):

public class NewMessagesCountWebPart : WebPart
{
    private Label lblNewMessages;

    protected void CreateChildControls(int i)
    {
        CreateChildControls();
    }  
    protected override void CreateChildControls()
    {
        lblNewMessages = new Label();
        lblNewMessages.Text = GetMessageNumberText();

        this.Controls.Add(lblNewMessages);
        base.CreateChildControls();
    }

    private string GetMessageNumberText()
    {
        using (SPSite site = new SPSite("http://sharepoint.typemock.com"))
        {
            using (SPWeb web = site.OpenWeb())
            {
                SPList messages = web.Lists["Messages"];
                int numberOfItems = messages.ItemCount;
                if (numberOfItems == 0)
                {
                    return "No new messages.";  
                }
                else
                {
                    return "New messages: " + numberOfItems;
                }
            }
        }
    }
}

Obviously, the problem is the private GetMessageNumberText method. Let’s see how Moles handles the faking. Take a deep breath:

[HostType("moles")]
[TestMethod]
public void GetMessageNumberText_ZeroMessages_NoNewMessagesText()
{
    // Arrange
    MSPSite.ConstructorString = (site, url) =>
    {
        new MSPSite(site)
        {
            OpenWeb = () => new MSPWeb()
            {
                ListsGet = () => new MSPListCollection()
                {
                    ItemGetString = (nameList) =>
                        new MSPList()
                    {
                        ItemCountGet = () => { return 0; }
                    }
                },
                Dispose = () => { }
            },
            Dispose = () => { }
        };
    };

    // Act
    NewMessagesCountWebPart webPart = new NewMessagesCountWebPart();
    string result = (string)
        typeof(NewMessagesCountWebPart)
        .GetMethod("GetMessageNumberText",
            BindingFlags.Instance | BindingFlags.NonPublic)
        .Invoke(webPart, null);

    // Assert
    Assert.AreEqual("No new messages.", result);
}

Notice the Lambda manipulation, and man, if you get it wrong, you need to dig deep. Another thing to note is the need to specify the empty implementation for the Dispose methods. The implementation is to throw if not specified. Finally, there’s the reflection use for invoking the method under test, not so big deal, but something you need to understand as well.


Behold the Isolator test:

[TestMethod]
public void GetMessageNumberText_ZeroMessages_NoNewMessagesText()
{
    // Arrange
    var fakeSite = Isolate.Fake.Instance<SPSite>();
    Isolate.Swap.NextInstance<SPSite>().With(fakeSite);
    Isolate.WhenCalled(() =>
        fakeSite.OpenWeb().Lists["Messages"].ItemCount)
        .WillReturn(0);

    // Act
    NewMessagesCountWebPart webPart = new NewMessagesCountWebPart();
    string result = (string) Isolate.Invoke.Method(webPart, "GetMessageNumberText");
    // Assert
    Assert.AreEqual("No new messages.", result);
   
}
I like this better.
Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More