Back at Microsoft, I was known for writing code with very few bugs. Testers often had trouble finding any bugs in my code. Is that because I wrote perfect code the first time? No way! It’s because I wrote automated tests for my code.

I proved this once again a few weeks ago. I wrote an application that would help us with our Knockout Nerd business. Since the code was very experimental and changing a lot, I just manually tested it. That was fine for a while. But when the code settled down a bit, I started writing some automated tests. And then I found the bugs.

That’s usually how my development process works. I write some code and manually test it for a while. But once it settles down enough, I write automated tests for it. Some people subscribe to the “test-driven development” process where a developer writes a test (which fails), and then writes the code to make the test succeed. I do that sometimes — but I’m not religious about it.

You can see examples of tests I’ve written in the BrickUtilities open source project. Here’s an example:

 [TestMethod]
 public void WantListItemTests_Create()
 {
     var item = new WantListItem(
         WantListItemType.Part, "3001", new BrickUtilities.BrickLink.WantListColorId(20), 5.1, 100, 50);
     Assert.AreEqual(WantListItemType.Part, item.ItemType);
     Assert.AreEqual("3001", item.ItemNumber);
     Assert.IsNotNull(item.ColorId);
     Assert.AreEqual(20, item.ColorId.Value);
     Assert.AreEqual(5.1, item.MaximumPrice);
     Assert.AreEqual(100, item.MinimumDesiredQuantity);
     Assert.AreEqual(50, item.QuantityFilled);
 }

This piece of code creates a WantListItem object with particular values. It then verifies that each value was set correctly. That’s a very simple test — others are much more complicated. BrickUtilities has dozens of different tests — all of which I can run in a matter of seconds to verify that everything is working. That’s how I like things to work!