RSS
Facebook
Twitter

Friday, August 28, 2009

Book Review: IronPython in Action

If you’ve been reading my blog for a while you might have noticed that I’m in the process of learning IronPython, Half way through my IronPython project I felt I was missing something, Although I have read Dive Into Python I had a feeling that I’m actually writing Python and that I need a more IronPython focused book that will teach me how to write dynamic code that uses .NET as well, luckily for me I stumbled upon IronPython in Action and found exactly what I was looking for.

Writing a book that would explain a new technology and still manage to keep the reader interested is hard enough when writing to a specific audience but the authors of this book managed the same with two different kind of readers – the book is intended for .NET developers that have some C#/VB.NET experience as well as Python developers that used one of the many flavors of Python. image

The 1st chapter of the book teaches Python (for .NET developers) and basic .NET (for Python developers) and explains what IronPython is all about. It’s amazing that after reading this chapter - only 28 pages long, the reader can start reading and writing IronPython code. 

The 2nd chapter takes the basics learnt in the previous chapter and shows the reader how he can take advantage of .NET WinForms to write a simple document editor. The reader also learns about Dynamic types and how to work with XML (in Python and .NET) and even how to unit test IronPython code.

But this book is much more then just an IronPython book, It’s also a design pattern book – using the example application is manages to teach several design patterns (MVC, command and observer to name a few).

But that isn’t all many of the widely used .NET technologies are shown in the third chapter along – WPF, ADO.NET, ASP.NET,  WebServices (SOAP and REST), PowerShell and silverlight. Each technology is explained and shown and then the reader learns how he can use IronPython with that technology.

The fourth chapter is all about using IronPython from C#/VB.NET and vice versa. It has examples in VB.NET and C# and manages to explain a few differences between these languages along the way.

One of the important aspects of learning new language is learning on the tools needed for development, I was pleasantly surprised to find that the authors didn’t forget to show the reader the available IDEs and libraries that he can use for development along with small tutorials and thoughts on their usage.

 

The book is a good read and manages to transfer the authors (Michael Foord and Christian Muirhead) experience and knowledge on IronPython.

So if you’re a .NET developer that wants to learn what dynamic programming is all about or a CPython developer looking for a way to enter the .NET world you really want to read this book.

Thursday, August 20, 2009

Checking expected exception message when using MS Test

In Typemock we use both NUnit and MSTest to run our unit tests. This practice enables us to check that Isolator works fine on both unit testing framework. Most of NUnit attributes can be translated fully into MSTest attributes (and vise-versa) there is one attribute we tend to use that works differently in MSTest - ExpectedException.
ExpectedException attribute is used to specify that a test should throw an exception to pass, both framework let the user define the type of the exception thrown (i.e. typeof(ApplicationException)) the big difference between the framework lies in the 2nd (optional)  parameter of that attribute - the Message.
While NUnit compares the massage to the exception's message MSTest does not. At first I though it was a bug but further investigation revealed that this was done intentionally, Microsoft decision was that the message should be only descriptive and used to associate a message to the exception and not check it.
So what could a TDD developer do if he wants to write a test that checks the exception message as well?
One solution is to add code to the test to check the exception's message:
[TestMethod]
[ExpectedException(typeof(ApplicationException))]
public void AddNewUser_UserEmailIsEmpty_ThrowException()
{
    try
    {
        // This line should throw an exception
        UserConnector.AddNewUser("user1", "");
    }
    catch (ApplicationException exc)
    {
        Assert.AreEqual("Error: user's email address missing", exc.Message);
        throw;
    }
}
You can read more about this method at IMistaken Blog.
The problem with this solution is that whenever I need to check an exception message I need to write ~4 more lines of code that makes my test less readable and somewhat error prone.

After digging a bit on the net I found a better solution, it seems that both XUnit and MBUnit uses Assert.Throws method instead of an attribute to check for expected exceptions.
First I've created a new class MyAssert that handles the exception verification logic:
public class MyAssert
{
    public static void Throws<T>(Action action, string expectedMessage) where T : Exception
    {
        try
        {
            action.Invoke();
        }
        catch (T exc)
        {
            Assert.AreEqual(expectedMessage, exc.Message);

            return;
        }

        Assert.Fail("Exception of type {0} should be thrown.", typeof(T));
    }
}
Then all I needed to do is use the new class whenever I needed to test for an exception and verify its message:
[TestMethod]
public void AddNewUser_UserEmailIsEmpty_ThrowException()
{
    MyAssert.Throws<ApplicationException>(
        () => UserConnector.AddNewUser("user1", ""), "Error: user's email address missing");
}
Although this solution seems more complicated at first it does have two advantages:
  1. I don't need to write the verification logic anymore
  2. I can specify the exact line in which I expect the exception to be thrown from.
Some would claim that using Throws is an over specification of the test but I don't think so. If using Assert calls during unit tests to check that specific line of test returned specific value is fine so does testing that a specific line throw a specific exception is acceptable as well.
After using MyAssert.Throws for a while I have to say I prefer it to using ExpectedException attribute because of the specific meaning it bring to my unit tests.

Tuesday, August 18, 2009

At office we have a Xerox printer that don’t have a driver for windows7 (yet?), but I still manage to print from it without any hassle. How – simply by using the incredible XP Mode.

The bane of the last two windows OS (Vista and Win7) was lack of driver support, although win7 has better support you can still find several vendors that still don’t have drivers for their products especially for the 64bit OS version.

Luckily the new Virtual PC/XP Mode supports external devices and setting a new hardware is as easy as it was on windows XP.

  1. Download and install the newest versions (RC) of Windows Virtual PC and Windows XP Mode.
  2. Start the newly installed virtual XP and add a new printer. You might need to change the computer domain to your work domain as well.
  3. Print whatever you need.

 

Now I don’t need to wait till Xerox release a Win7/64bit driver for my OS.

Saturday, August 01, 2009

XmlWriter that automatically close elements using IDisposable

System.Xml.XmlWriter provides an easy and lightweight way to write xml strings, unfortunately it has a little gotcha. consider the following xml string (borrowed from IronPython in Action):

image

Using XmlWriter the following code is needed to create that string:

image

Keep in mind the fact that the code above only creates 5 lines of xml, and as you can probably tell it has a very distinct overhead – for each element/document created you must add a WriteEndX statement, the code quickly becomes unreadable and could create an invalid xml string if a WriteEndElement is misplaced or forgotten.

It occurred to me that closing an xml element should not be different from closing a resource which led me to think about using the trusted .NET IDisposable interface:

Lightbulb - Darren Hester

image

AutoCloseNote is a simple class that implements IDisposable and run a predefined action when disposed.

image

AutoCloseXmlWriter has similar methods to the XmlWriter class (I’ve only implemented two in this example) and returns a AutoCloseNode that will run the "WriteEndX method on disposing.

And now we can transform the code from the beginning of the post to this:

image

We got rid of the need to remember when to call the end element method and we got indentation of our code according to the xml string it represents free of charge.

 

As you can see we can use this neat trick to create a (more) readable code, do you know of any other examples? (hint: Typemock Isolator)

Related Posts Plugin for WordPress, Blogger...