Category Archives: .NET

general musing about .NET and related technologies

How do you start a new project with TDD?

Bobby Johnson (@NotMyself on Twitter) wrote a post detailing how and why he “tests reality” when he starts a new project and gives two examples of what he means.


'use strict';

var assert = require('assert');

exports.test_reality = function(test) {
    test.equals(true, true, 'true should still be true');


using NUnit.Framework;

namespace Simple.Data.SqliteTests
    public class RealityTests
        public void true_should_be_true()

At first glance, you look at those and think they are silly because all they are doing is testing that the test framework is working correctly. But Bobby has a different reason for including them.

So when I am setting up my basic project structure and automation, I like to have at least one unit test ready to run. This allows me to test the automation script and ensure failures in tests cause failures in builds. In .NET I want to confirm that the compilation step fails properly and the unit tests fail properly. In node.js, I want to ensure that linting errors fail as well as unit tests.

That’s a valid point, however this is more of a configuration test of your infrastructure. I personally wouldn’t write a test like this, I’d want the test to have some value before I committed it to the main repository or build/CI server. I strongly feel that developers should use the same build procedure on their desktops to build the application as they do on their CI server. IDE’s like Visual Studio abstract away the building of the application, so we often have to write scripts, rakefiles, psake files, whatever to do all the things that Visual Studio doesn’t do when it builds your application. Things like running the tests and reporting the results, building an installers or setting test/staging/production values in config files. I like to have a repeatable build system setup for projects I’m working on so I tend to re-use scripts or keep it really simple. Which means that I have confidence that I have configured the build script correctly so that it will work properly when I put it in my CI server. Which allows me to start focusing on the design of my application sooner.

How far behind are Microsoft developer frameworks in terms of design?

From the article “Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson


Erich Gamma: Yes, and it is funny that you mention the iPhone. The iPhone SDK is based on the NeXTStep object-oriented frameworks like the AppKit. It already existed when we wrote Design Patterns 15 years ago and was one source of inspiration. We actually refer to this framework in several of our patterns: Adapter, Bridge, Proxy, and Chain of Responsibility.

Richard: Which is a great example of the enduring nature of good design, and how it survives different technical manifestations.


Emphasis mine.

In the Microsoft developer community, we are just now getting around to implementing patterns like MVC, Adapter, and Observer. People still argue over whether or not the MVC pattern is “necessary” to build a “working application”.


I guess it depends on whether or not you like good design?

Mocks versus stubs and fakes

I dislike using mocks I dislike using dynamic mocking/stubbing frameworks. because it means my tests have an extra dependency beyond just the SUT (System Under Test). I often find myself spending more time getting the mock to work correctly rather than my app code. The lambada + generics based Mock suites (Moq, RhinoMocks, etc), IMO, complicate the test and make them unreadable in some situations.


Compare the two examples in this post. One uses RhinoMocks to create a stub of IDataReader and the other uses the DataTableReader to create a stub for the test. Which example is simpler and has less chance to fail due to the stub?

Using RhinoMocks

IDataReader reader = MockRepository.GenerateStub<IDataReader>();
            reader.Stub(x => x.Read()).Return(true).Repeat.Times(1);
            reader.Stub(x => x.Read()).Return(false);
            reader.Stub(x => x["ID"]).Return(Guid.Empty);
            reader.Stub(x => x["FullName"]).Return("Test User");

Using DataTableReader

DataTable table = new DataTable();
            DataRow row = table.NewRow();
            table.Columns.Add(new DataColumn("ID"));
            table.Columns.Add(new DataColumn("FullName"));
            row["DirectoryUserID"] = Guid.Empty;
            row["FullName"] = "Test User";
            DataTableReader reader = new DataTableReader(table);

Stubs/Fakes allow me more control over HOW the test fails and results in a test/fixture that is easier to read. I’m not saying that mocks aren’t useful in certain situations, but I would favor a stub over a mock IMO, your test should only fail because of the code it is testing, not because of a mock.


Although it is fun to say "Mock ME? No mock YOU!".

update: I forgot to link to Rob’s post that inspired this post. “Using Dependency Injection and Mocking For Testability

update to the update: Jeremy Miller and Nikola Malovic both pointed out that I’m using the terminology incorrectly. It turns out I don’t specifically hate mocks themselves, I dislike use dynamic mocking/stubbing frameworks due to the extra dependency they introduce into my tests. Thanks for the corrections. Back to reading Fowler for me!

JavaScript: Not for the faint at heart?

JavaScript: A tool too sharp?

Script# (Script Sharp) – writing javascript in C#

Both Jimmy and roy have great posts discussing JavaScript. Roy is looking at it as a C# developer lured by the many, many articles about how jQuery is the only thing that makes JavaScript worth using and using Script# to abstract away some of the messiness and pain usually associated with writing JavaScript. Jimmy discusses the merits of JavaScript itself and how it has changed how he approaches writing C# code.

One thing I like to point to is a great quote I heard on Twitter

Java is to JavaScript as ham is to hamster


JavaScript actually has more in common with Scheme or Lisp than it does Java or C#. I first realized this when I saw that Douglas Crockford had re-written all of the examples in The Little Schemer
in JavaScript. It’s easy to miss that fact when you see all of the pseudo OOP noise like “var foo = new Foo();”. But when you see how trvial it is to implement something like a map method in JavaScript, you realize how powerful the language can be. Most of the hatred for JavaScript comes from two things I’ve found:

  1. Broken DOM implementations – every browsers implementation of the DOM is broken in one respect or another.
  2. A misunderstanding of either scope or inheritance.

Roy has a great point about the lack of good tooling surrounding JavaScript. There are excellent libraries like jQuery and PrototypeJS, but the usual tool support, intellisense, re-factoring, profiling, is a little more difficult to come by. I’ll address this in another post as I feel a lot of people are new to JavaScript and are struggling along with some substandard tools.

Review: IronPython in Action

I’ve always wanted to use Python more but it’s difficult because the .NET Framework is such a walled garden in terms of interoperability with other programming languages. Mostly I use it to write little one off scripts when I want to move a bunch of files around or parse some text. I was really excited when Manning asked to to review IronPython in Action because I wanted to dive a little deeper into Python and possibly use it in some web applications. “IronPython in Action” makes it easy to get started using IronPython right away.

The book starts out with an introduction to Python itself and continues with a general description of how IronPython can use .NET types. It starts off by showing how to build a Winforms app using IronPython. If anything exposes the cruel, unnecessary complexity of .NET, it’s got to be a Winforms app. The IronPython examples are easy to follow and it’s always fun to create and manipulate a Winforms app using the IronPython console.

Chapter 4 talks about using Design patterns in IronPython. This is a refreshing change from most language books where patterns aren’t mentioned at all. The chapter builds an IronPython application and uses the MVC pattern for the overall architecture and the command pattern for the implementation of the menu bar events.

Chapter 7 discusses agile testing and unit testing using IronPython. I almost dropped the book in amazement. Unit testing is almost never mentioned in any language book and is relegated to a niche or advanced topic. Find a book about any other .NET language that mentions unit testing that doesn’t have the word “testing” in the title. This alone sets the quality of this book far above other language books I have read. It’s not just enough, in my opinion, to discuss the syntax of the language. You have to teach the reader how to use the language in your everyday work.

The next section, section3, deals with a few core UI frameworks commonly used during .NET development, WPF, Silverlight, and ASP.NET, as well as showing how you can use IronPython to administer your system. Performing tedious tasks is my most common use of IronPython. I use it to automate moving files that fit a specific pattern out of my “downloads” directory to their proper places. It was great to learn a few new techniques for using IronPython in Powershell.

The last section talks about extending IronPython using C#, something which it sounds like should be avoided unless you just can’t achieve decent performance with the equivalent IronPython code, and using IronPython as an embedde scripting engine. Python is used a lot in game programming because it’s easy to embed. The nuts and bolts of the game engine will be written in low-level C/Assembly while the game logic and story is written in Python. I love the idea of having an embedded scripting engine in my application that will allow me to quickly extend my application at runtime. The user need to perform a new calculation on some data? Just send them an IronPython script and have them put it in a directory. It’s a great idea and the book describes exactly how to do just that, even if it does use a little too much jargon at times. These are advanced topics and you probably shouldn’t undertake them unless you have a good understanding of the basics in any case.

My overall feeling about this book is that it’s a great book. The authors use the same humor and dry wit that Python is known for to great effect. Making the digestion of a very different language easier. I’m sure that as I continue to experiment with IronPython that I’ll keep this book close at hand.

Why these jQuery worst practices aren’t.

jQuery … Worst Practices

In this post, Steve Wellens tries to make the case for two common patterns your run across when using jQuery as “worst practices”. Practices that are either superfluous or harmful to your code.

1) Wiring up events using unobtrusive JavaScript.

Instead of wiring up your elements events using jQuery, instead you should set the OnClientClick property of the ASP.NET Web Control in question and call whatever JavaScript you want to handle the event.

Instead of this:

    <script type="text/javascript">

                alert("You Clicked Me!");


Do This:

    <asp:Button ID="Button1" 
                OnClientClick="alert('You Clicked Me!');" /> 

His reasoning is as follows:

You might want to change event handlers dynamically depending on some condition in the page. If you need to assign a common event handler to several objects on a page, it makes sense to do it in one place. As a matter of fact, that’s the beauty of jQuery. But for a single event on a single control….NO.

On can debate whether or not a worst practice can really be applied to a single, specific , one-time event or not. But there are other reasons why you might want to hook up events to a single element using jQuery. one being that you can’t hook up multiple event handlers using OnClientClick or HTML’s OnClick event, only a single event handler can be assigned. If you are using the observer pattern in your JavaScript, you may have multiple observers that want to subscribe to your buttons click event. But a really strong argument could be made for using the OnClientClick property simply due to ASP.NET’s suck-ass way of handling client IDs.

2) Chaining can lead to unreadable code.

In a badly written example, he states that chaining calls to jQuery makes the code unreadable. I’d suggest re-formatting the code in this manner to make it legible and allow for a tighter minimization.

  .css("color", "yellow")
  .css("background-color", "black")
  .css("width", "50px");

Of course, you wouldn’t write jQuery code like that and call the css method multiple times. Ideally, you would just set a class or at the very least pass in a set of properties in an object.


3) Comment your code.

// get all the Divs with the highlight class and
// format them and set their width

var Divs = $("div.highlight");
Divs.css("color", "yellow");
Divs.css("background-color", "black");
Divs.css("width", "30px");   

I like this explanation by Jeff Atwood best. If you need comments to explain WHAT your code is doing, you need to use better names and/or write better code. Comments are best when used sparingly and explain the WHY of the code. Why did you choose to use a particular algorithm