C# 4.0 Dynamic Types Allows Better Unit and Automated Tests

I noticed today that C# 4.0 will offer dynamic typing (no, your keyboard will not type magically for you…the other typing). Why mention it here? Well, if I understand the new feature right, this will fix a fairly large unit testing and automation roadblock caused by static types. For example, when writing tests in .NET and trying to consume/use a method on a .NET API or Web Service your tests are constrained to the method’s inputs static types at compile time. In other words, in the old C# world, if you had a method that looked like this:


public void testMe(int foo){ }

and you wrote a test that called the method like this:

testMe( “poofoo” );

the test would fail at compile time due to static typing (because the method’s input parameter type is an int, but we’re trying to pass a string)

Thus the roadblock I was describing… There are a lot of tests, poor error handling, AND hidden defects when you try to pass invalid types into inputs in a service. So, about now you are saying…”Who gives a crap Brent, if my service’s consumers use .NET they’ll compile, get the error and never even get a chance to send a string in where an int should be”. There was a day when I thought the same thing (a long time ago), until I consumed a Web Service using a Java application. For example, say you’ve exposed a .NET Web Service for the world to use… and I come along and consume it with Java, by doing that I can ignore your static/strong typing and send in that string that you weren’t prepared for. Strings don’t work so well as ints (especially when it’s “poofoo”, or even better “2147483648”). Most of the time the errors are just plain ugly, making the API or Web Service really hard to work with when trying to do good error handling management (imagine getting “you failed, line 67”, but then a code change occurs and now it’s line 68), but sometimes things fail on a larger scale and make some really cool defects.

Back to the point…

I’m thinking the new dynamic type in C# 4.0 will allow you to avoid that compile error if you’re writing your tests using C#/.NET. Thus, I could send in that string as an int and then see what happens at runtime. That test would look something like this:

dynamic poo = “poofoo” ;
testMe(poo);


Neither confirmed or denied at this point, but if true, I’M REALLY EXCITED. This will fix a major issue that I’ve had with testing .NET services using .NET.


It’s interesting the conversations that are spawned from the issues that come out sending invalid types…


Brent: The error message… “You failed, line 67” is poor and confusing, what did I do wrong?

Developer: It choked when you sent in the wrong type. Don’t do that.

Brent: That sucks…so when our customers do the same thing and then call in for help we’ll just tell them that?

Developer: Well, uh..no. Okay, I’ll put in a little error handling and a descriptive error message.

Brent: Sweet!

Brent: (Evil laugh in head) Hey… Will we support that error message as part of the API? Because, if you make it a message that I, a consumer can rely on, that means my code will depend on it, meaning that changes to the error are breaking changes. Breaking changes must be tracked and documented.

Developer: (Slowly backing away) I CANT HEAR YOU!!!

One Response to C# 4.0 Dynamic Types Allows Better Unit and Automated Tests

  1. Alexey Romanov says:

    From the description of the way dynamic typing will work in .NET, this will obviously fail at runtime. How could it do anything else? Take

    dynamic poo = "1";
    testMe(poo);

    The runtime will just look for

    testMe(string)

    and when it doesn’t find it, for

    testMe(X)

    where X is something to which string can be converted implicitly. Since string can’t be converted to int, it fails.

Leave a Reply

Your email address will not be published. Required fields are marked *