Practical .NET Unit Testing – Free paper released

I've been working on a unit testing paper that sums up my experience in unit testing, and discusses some of the core information that I feel is important about the subject. It's very much a work in progress, but I wanted to get it out sooner rather than later. I'll be continuously updating it as time goes on.

Update: I updated the PDF location to one that doesn't require registration.

Practical .NET Unit Testing

There are some really great books out there about unit testing, but I think some of them are trying too hard to be long enough to be considered a "book". I set out to create a document that fills the gap between the various snippets of information from blog posts, and the comprehensive books on the subject. If you're interested in something a bit more in-depth, here are some great books on the subject:

The paper currently consists of 5 main sections:

  • Why Write Unit Tests?
  • Unit Test Mechanics
  • Common Unit Testing Strategies
  • Designing for Testability
  • Advanced Techniques

Here is a more complete snapshot of the current outline:

  • Introduction
  • Unit Testing & Managers
  • What Unit Tests Really Do
  • Types of Testing
  • Testing Framework
  • Test Runner
  • Unit Test Structure
  • Other Test Attributes
  • What is Refactoring?
  • Test Driven Development
  • Evolving Code
  • When Should You Write Unit Tests?
  • Test is for Functionality, Not Code!
  • The Constraints of Reality
  • Interfaces - Quick Overview
  • Using a Mocking Framework
  • Stubshe Test Driven Design Paradox
  • Testing Under Pressure
  • Extracting Duplicate Logic
  • Modular Design Benefits

So what are you waiting for? Go check it out online instantly, you can even download it as a PDF if you like. Is anything missing? Is anything just plain wrong? I'd love to hear your feedback.

Remember, if you want to hear more about unit testing, I'll be speaking in Northeast Wisconsin Saturday, May 9th.

Like this post? Please share it!

See a mistake? Edit this post!

Speaking at Day of .NET at Fox Valley Tech

If you're interested in hearing about writing practical unit tests in .NET, I'll be speaking at the Fox Valley .NET user group "Day of .NET" event May 9th! Here is the synopsis for your reading pleasure:

Want to learn how to write good automated unit tests that are beneficial both to the product/customer and to you as a developer? See an overview of the mechanics of unit testing including the tools and frameworks available. You'll see examples of how to test existing code, but you'll also see practical examples of how seemingly un-testable code can be designed so that it can be tested with ease. Learn how test driven development and refactoring will improve the readability of your code, minimize debugging, and speed up development.


If you're anywhere near the Northeast Wisconsin area, stop in. It's free!

I'll be publishing both the presentation and a supporting 25+ page paper shortly, so make sure you're subscribed to my feed.

Fox Valley Tech is located at:
1825 N. Bluemound
Appleton, WI 54912

Like this post? Please share it!

See a mistake? Edit this post!

int inherits from object? An investigation into how.

I've began working with a study group which was formed to study for the .NET Framework Application Development certification exam (70-536). I'm eager to get certified because I think it helps fill-in knowledge gaps that I may not have necessarily took the time to focus on normally. One of the first things that came up in our study group is the fact that int, which is an alias for System.Int32, derives from Sytem.ValueType, which, in turn, derives from System.Object. Let's take a close look at what that actually means, and how it's implemented.

When I first heard that int ultimately derived from Object, I didn't believe it for a number of reasons:

  • If you inherit from Object, that derived object IS an object
  • If int is a subclass of Object, then boxing isn't necessary

The truth is, my assumptions were not correct. The .NET team, for consistency sake, made all types fit nicely into the type hierarchy:

Object Hierarchy

If the .NET team had built System.Int32 to work like any other reference type, there would be clear performance issues. In reality, we need value types to be lean and mean. They are stored on the stack (instead of the heap for reference types). To do this, there is some internal "magic" going on that treats objects that inherit from ValueType differently. Behind the scenes it optimizes how they're used to get the best of both worlds. If you try to inherit from ValueType, you'll get a compiler error, because it is only exists for build-in value types.

Of course we want our cake and we want to eat it too. There are often times when you want to use a value type in a method that takes an object as a parameter. To keep up the illusion that a value type is an object, the framework employs boxing. It effectively wraps the value type inside of an object.

Let me out, I'm an object!

Take a look a the following code:

public string GetObjectString(object obj)
    return obj.ToString();

public void IntAsObject_Boxing()
    var str = GetObjectString(4);
    Assert.AreEqual("4", str);

And look at the corresponding IL for the test method:

IL_0001:  ldarg.0
IL_0002:  ldc.i4.4
IL_0003:  box        [mscorlib]System.Int32
IL_0008:  call       instance string _4_17_09_Boxing.UnitTest1::GetObjectString(object)
IL_000d:  stloc.0
IL_000e:  ldstr      "4"
IL_0013:  ldloc.0
IL_0014:  call       void [Microsoft.VisualStudio.QualityTools.UnitTestFramework]Microsoft.VisualStudio.TestTools.UnitTesting.Assert::AreEqual<string>(!!0, !!0)
IL_0019:  nop
IL_001a:  ret

Notice that boxing occurs on line 3. It's using the IL "box" command to let you stay oblivious to the fact that there is some magic going on behind the scenes.


The end result is that we have an integer, which is an object, but isn't really, that needs to be wrapped inside of an object, which shouldn't be necessary, but is because it is. :-)

Does this really matter? Well, not really. For the most part you don't need to know this. If you're truly inquisitive and want to know what's going on, you may find it interesting.

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG