Chris Missal

If there’s one thing I like about programming computers, it’s the ability to tell a machine exactly what to do. --insert Skynet reference here-- With that said, I wanted to learn some more tips, tricks and techniques to figure out what exactly computers are doing when they’re misbehaving. I decided to grab a copy of Debug It! by Paul Butcher just to see what a whole book on debugging could possibly be all about. Initially I thought it would run dry of good topics early on, but there’s plenty to read about in this title.

Finding and Fixing Errors

Part of debugging is the ability to locate and eliminate defects. The book gave some really helpful tips on how to reproduce and diagnose bugs. Some of these are common sense, others aren’t so obvious. The author talks about how you can benefit from another person looking at it as well as keeping a log of all the “things” you’ve tried. Oftentimes, if you’re like me, you might even forget that a bug is anything that the software is supposed to do, but doesn’t do!

Preventing Bugs

Working in a bug free environment is great, but keeping the bugs away is difficult. “The Bigger Picture” section of the book does a nice job of talking about maintaining quality and preventing bugs from popping back up. Zero tolerance for defects and giving bugs top priority has certainly helped a major project I’ve worked on be a huge success. Keeping track of your defects with tracking software right from the get go is a pretty good idea, you’ll hear about that when reading this book.

More on Code Quality

While the book is primarily focused on how to avoid and remove defects, Paul also goes in depth on many other software development practices that support quality. Unit testing, source control, automation and project management practices. There’s a lot more than bug-squashing in this book, there’s a lot of good info on writing code that works. We all love code that works!

What Did I Think?

Overall, this was a really good read. There wasn’t anything Earth shattering, but it did align with some of my approaches to defects, as well as reinforce the things I don’t always do so well. Pablo and I give this one 5 out of 5 donkeys! Here’s a few things I’m going to try to keep in mind as I debug in the future:

• Don’t allow for black magic
  • “Weird, that must have just been an anomaly” – No, it probably happened for a reason. What reason? Find out!
  • “For some reason it XYZ’d” – If it does it once, it could probably happen again.
• Reflect on defects more:
  • Why did this bug occur or not get caught in the first place?
  • How can we avoid something like this from happening again?

Who Should Read This Book?

I think that this book should be read by all new software developers as well as all junior or mid-level developers. There’s plenty to be learned by the senior developer types too. Even if you’ve been doing these things for a long time, this is a good read to make sure you’re keeping your feet planted firmly on the ground.

 

Today when modifying what we call an “order notifier” (essentially observers that are notified when an order is placed), I was having trouble figuring out why my test was failing. The project is written in C# and this test was using Rhino Mocks to isolate the EmailService class. We obviously don’t want to test our code with an actual email implementation, so a mocking/isolation framework is a perfect tool for abstracting this out and making testing easier.

The TestFixture and Test I Wrote

Below is a very verbose version of the test class using NUnit. The actual tests use some shared methods for setting up the order and making assertions on the email service. I opted to show more code just so it’s easier to see all the setup and verification that was going on.

[TestFixture] public class Tests { private IEmailService emailService;   [SetUp] public void SetUp() { emailService = MockRepository.GenerateMock<IEmailService>(); }   [Test] public void Notify_should_contain_OrderNumber_and_CustomerNumber_if_Order_NeedsShippingQuote() { const int customerNumber = 1337; const int orderNumber = 2401; var order = MockRepository.GenerateMock<IOrder>(); order.Stub(x => x.OrderNumber).Return(orderNumber); order.Stub(x => x.CustomerNumber).Return(customerNumber); order.Stub(x => x.NeedsShippingQuote).Return(true);   var notifier = GetNotifier();   notifier.Notify(order);   emailService.AssertWasCalled(x => x.SendOrderReceived( Arg<string>.Is.Anything, Arg<string>.Matches(body => body.Contains("This order needs a shipping quote.") && body.Contains(customerNumber.ToString()) && body.Contains(orderNumber.ToString()) ))); }   public CustomerServiceNotifier GetNotifier() { return new CustomerServiceNotifier(emailService); } }

The only additions to this test were those asserting that the email’s message body contained the customer number and the order number. With these new expectations set up on the CustomerServiceNotifier, it was time to write the code to make that expectation valid.

The Notifier Code

Some of this code was removed because it’s either not important to this post, or just too lengthy. This is a trimmed down version of the actual implementation.

public class CustomerServiceNotifier { private readonly IEmailService emailService; private const string ORDER_NOTES_FORMAT = "{0}{1}"; private const string SHIPPING_QUOTE_FORMAT = "<br />This order needs a shipping quote:<br />Order #: {0}<br />Cust #:{1}";   public CustomerServiceNotifier(IEmailService emailService) { this.emailService = emailService; }   public void Notify(IOrder order) { var emailBuilder = new StringBuilder();   if (order.HasNotes) emailBuilder.AppendFormat(ORDER_NOTES_FORMAT, order.OrderNumber, order.OrderNotes);   if (order.NeedsShippingQuote) emailBuilder.AppendFormat(SHIPPING_QUOTE_FORMAT, order.OrderNumber, order.CustomerNumber);   if(emailBuilder.Length > 0) emailService.SendOrderReceived(order.EmailAddress, emailBuilder.ToString()); } }

The notifier was changed to format the “needs shipping quote” message to contain the order number and the customer number. If you’ve already spotted the mistake, nice work, I didn’t find it so fast.

The failure stated the following:

IEmailService.SendOrderReceived(anything, body => ((body.Contains("This order needs a shipping quote.") && body.Contains(1337.ToString())) && body.Contains(2401.ToString()))); Expected #1, Actual #0.

I knew that the method was being called. I couldn’t figure out why it was giving me the error message at first. I decided to take advantage of Rhino Mocks’s WhenCalled method. This allows you to provide a delegate to do some fancy stuff when that method is called. I just decided to use some simple output so I could see the actual string that was being passed to the mock email service. That was done pretty easily:

[SetUp] public void SetUp() { emailService = MockRepository.GenerateMock<IEmailService>(); emailService.Stub(x => x.SendOrderReceived(null, null)).IgnoreArguments() .WhenCalled(x => Console.WriteLine(x.Arguments[1])); }

After I generate my mock, I just stub out the method, ignoring any arguments, and output the second argument to the console. I re-ran the test and it gave me the output like so:

<br />This order needs a shipping quote:<br />Order #: 2401<br />Cust #:1337

It only took me one look to see the problem and scream think: Doh!! The actual text contains a colon character after “quote” instead of my test which was expecting a period character. The character was changed, I removed the WhenCalled delegate set up and I was back to good. This idea seemed like a nice way to do some debugging without having to slowly step through the code.

Some Thoughts on the Problem

I’m all for writing good tests and adhering to best practices and while my unit test above technically only contains only one assertion from Rhino Mocks (a good idea), it’s actually making 3 assertions total (not so good). I’m checking that the email body contains some text, an order number and a customer number. I really should break this up into 3 separate tests since it’s checking 3 requirements within the email body. I guess I have something to do tomorrow morning. :)

Some Thoughts on Rhino Mocks WhenCalled Method

I’ve found myself using this more and more lately when stubbing out test setup. Primarily when using the WhenCalled method I’ve been thinking of it in my head as a “pass-through”. I want to ask for an object given some specific data and get back a fake object of that type that matches on the value I passed in. I’m not sure if the thought in my head is making sense, so I’ll give some sample code.

The following IScheduleResolver interface is meant to provide an ISchedule back when called. I don’t really want to set up a new fake object for all the variations passed in, I just want to return a schedule that is valid (or possibly invalid) for that time I provided. Here’s the setup of this idea:

scheduleResolver.Stub(x => x.GetCurrentSchedule(null)) .IgnoreArguments().WhenCalled(a => { var fakeSchedule = MockRepository.GenerateMock<ISchedule>(); fakeSchedule.Stub(x => x.IsValid((IClock) a.Arguments[0])); a.ReturnValue = fakeSchedule; });

Essentially what this is saying:

No matter what IClock value you pass into GetCurrentSchedule, I’m going to return a fake ISchedule that is valid for that IClock.

You could do the opposite of this too, of course. This has been very helpful in reducing some extra set up I might have otherwise endured during testing.

Last week marked the one year anniversary our team’s first ASP.NET MVC application in production. We really have two different types of production. Internal and external. While an internal application might get used by 2 to 100 people, our external applications get used by millions. After chatting with some members of the team and looking at the source code from a year ago, I’d like to share some thoughts with you. Let’s take a look back into the past, all the way back to the year 2009.

What Did We Learn? Sacrifices Were Made

I’ll be the first to admit that the project wasn’t where most of us wanted it a year ago, but the sacrifices we did make were consolations we were willing to live with. The easy one to point out is stuffing objects/data in ViewData. This seemed like a good idea at the time (and it was fast), but just gets messy in a hurry. You wont find this in many places anymore. We’ve been cleaning up that sort of thing while we’re in those areas and things look much tidier now.

Flexibility Was Achieved

The ability to cover our code with tests in MVC was much easier than the previous code in WebForms. This has allowed our code to be quite malleable. There are still some areas that are harder to test, but they disappear each week as we simultaneously see our code coverage marks rising.

Treat Routing With Respect

Routes are great, but they’re better when created earlier rather than later. If you’re starting on something new, be sure you thinking about your route conventions towards the beginning of the project and not as an afterthought. Wanting to change these up after the application is in production, you might have to end up breaking URLs or having to do some re-writing. The other big factor is realizing your site’s information architecture and how this is important to your site’s URL/directory structure. Big bonus points if you can nail this down right away and not have to worry about it after version 1.

Comments From the Team

With the ability to keep views small and concise I am left with significantly less (duplicated) code to wade through while working with CSS and jQuery. I've noticed a definite decrease in time spent working in individual files allowing me more time to spend on enhancements and improvements. This last year I've designed more pages and worked on far more new features than any other year before, and hoping to continue that trend into the next year. – Jessica

MVC provides the hooks to quickly and easily do what we want.  Case in point, the other day using in our dev session looking at overriding a "default" page with a custom page just by the existence of the page (view). With webforms this is possible but it's a pain with the page controller pattern dictating the flow of things.  This allows us to more quickly respond to the needs of the business with less code in a more discoverable location - arguing the code we implemented is much clearer than an HttpModule (with webforms). - Tim

What am I Looking Forward to in the Coming Year? Conventions, Conventions, Conventions

Nothing new here. The more time we spend in our code, the more certain parts of it look alike. Humans are good at spotting patterns and our group is very “humany”. (If that word isn’t invented yet… patent pending!) In all seriousness though, adhering to conventions can greatly reduce the time to market for new features, just ask the Ruby crowd. We’re finding more and more opportunity for conventions all the time.

Builders/Templates

Essentially just more conventions ideas. MVC2 will allow us to use model templates (like input builders in MvcContrib), that we’re likely going to be taking advantage of. The typical usage I’m seeing is input forms, but we don’t have tons of forms within our project. We do have a lot of code that can make use of jQuery and progressively enhanced displays as well as templating many of our repeated and/or similar models.

Thanks…

Obviously we’re not the only ones out there who use MVC. There seems to be many that are blogging about the pros/cons as well as giving tips and tricks on how to make MVC work better. I just want to say thanks, and keep it up!

Some time ago, I noticed a CruiseControl.Net build report with thousands of unit tests passed, zero failed and a dozen or so skipped, suddenly showing that no tests were run:

I immediately thought somebody did something really bad. After some digging, I found an error in the CCNET log file that indicated an error was thrown and swallowed during the parsing of the test results xml file. It was choking on an NUnit Row Test with a null character in a string. Here is the exception:

2010-03-02 13:45:25,567 [Project.Web:DEBUG] Exception: System.Xml.XmlException: '.', hexadecimal value 0x00, is an invalid character. Line 5901, position 160.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
   at System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String[] args)
   at System.Xml.XmlTextReaderImpl.ThrowInvalidChar(Int32 pos, Char invChar)
   at System.Xml.XmlTextReaderImpl.ParseNumericCharRefInline(Int32 startPos, Boolean expand, BufferBuilder internalSubsetBuilder, Int32& charCount, EntityType& entityType)
   at System.Xml.XmlTextReaderImpl.ParseNumericCharRef(Boolean expand, BufferBuilder internalSubsetBuilder, EntityType& entityType)
   at System.Xml.XmlTextReaderImpl.HandleEntityReference(Boolean isInAttributeValue, EntityExpandType expandType, Int32& charRefEndPos)
   at System.Xml.XmlTextReaderImpl.ParseAttributeValueSlow(Int32 curPos, Char quoteChar, NodeData attr)
   at System.Xml.XmlTextReaderImpl.ParseAttributes()
   at System.Xml.XmlTextReaderImpl.ParseElement()
   at System.Xml.XmlTextReaderImpl.ParseElementContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlWriter.WriteNode(XmlReader reader, Boolean defattr)
   at ThoughtWorks.CruiseControl.Core.Util.XmlFragmentWriter.WriteNode(XmlReader reader, Boolean defattr)
   at ThoughtWorks.CruiseControl.Core.Util.XmlFragmentWriter.WriteNode(String xml)

Here's an example that again broke our results output the other day.

 

This version of CruiseControl.Net isn't the newest, and is older than the version of NUnit that is running. This may be fixed by upgrading CCNet, I haven't tried yet though. This is just meant to be a "heads-up" in case you run into the same issue.

Unfortunately, my answer to getting the results to show back up was to remove both row tests.  If anybody can add more details to this (affected versions, fixes, workarounds, etc), it would be greatly appreciated by myself and hopefully somebody else.

I think there’s great benefit in not only knowing how to design your code to use common patterns but also to be able to speak about them clearly and concisely to others. If I mention that the problem sounds like it could be solved using the Strategy Pattern, somebody who knows what I’m talking about shouldn’t need much more of an explanation than that. Knowing certain terms in code will help with communication. Obviously, the better your team is at communicating, the more successful you’re going to be.

Very Simple Projection

I’ve seen the following code all over the place. It’s very common to turn one collection into another or loop through and capture certain properties of the items you’re enumerating. How often have you seen this code:

public IList<string> GetNames(IEnumerable<Person> people)
{
IList<string> names = new List<string>();
foreach (var person in people)
{
names.Add(person.Name);
}
return names;
}

This is simple projection, but languages are seemingly giving you better ways to achieve this same thing. I’ll get to that later.

Different types of projection

I see three basic types of projection. There are variations of these same ideas, but for the most part these cover the bulk.

• Selection: Imagine you have a collection of customers and you want only the email addresses, this is where selection projection would be used. This isn’t always a one-to-one relationship, your customers may have more than one email address (if you allow it) and you’ll end up with more items in the projected collection than the starting collection.
  
• Creational: This is the type of projection that returns new values from an existing collection. Below, you’ll see two concrete examples in C#.
  
• Transformation: Given a list of numbers, you want those numbers squared. This is similar to creational, because you'll be getting a new item, but it shouldn’t modify the elements in the original collection.

Projection with LINQ in C#

An example that lends itself well to the concept of projection is the following:

My user interface allows strings to come into my application. I want to transform these strings into tags like any blog post, video or photo might have assigned to it. I don’t want my tag service class to have to deal with strings, I want to give it a collection of Tag objects. How do I do this?

With LINQ, this creational projection was very simple:

public void SaveTags(IEnumerable<string> tagNames)
{
var tags = tagNames.Select(name => new Tag(name));
tagService.SaveOrUpdateTags(tags);
}

Another great use of creational projection are some of the usages I’ve seen with SelectListItems in the ASP.NET MVC space. Given a list of objects, create a list of HTML drop down items for a select list.

K. Scott Allen has a good write up entitled Drop-down Lists and ASP.NET MVC on this very thing. There are also many good examples over on the MSDN Visual C# Developer Center.

Your Thoughts on Projection…

I see this pattern often enough but I don’t hear the term “projection” nearly as often. Is there a more common name to this that I’m not hearing or are people just not referring to it by this name?

An ID is a fine way to uniquely identify an object, the common usage is also very user un-friendly. A while back I was watching a presentation by Jeffrey Palermo on Community For MVC.Net, then later at a live presentation and discussion at the local user group in Cedar Rapids. Not that it’s a new idea, but the idea of a Key and the IKeyable<T> interface was mentioned. This idea being a unique, human readable string. Throughout the rest of this post, when I mention “ID”, I’m speaking of an auto-generated number or meaningless string. When I mention a “Key”, I’m speaking of a meaningful string identifier that gives some sense as to what it is representing when a human reads it.

IDs in an Web Application

Sequential integers in a database are easy to come by and are guaranteed to be unique by the database. This makes things simpler since you’re not required to check for uniqueness. Another option is to use GUIDs. These are good because the chance of collision is extremely small and gives you hundreds of billions of combinations. Another unique ID that I’m seeing appear more recently is the incremented strings, where “ab89Fh” is the prior ID to something like “ab89Fg”. All of these solutions are great for keeping things unique from the data perspective, but are horrible for human memory.

Unique Keys in an Web Application

The concept is simple: a human-readable key that uniquely identifies an object. Why is a unique human-readable key a good idea? A key that is generated from some meaningful text is likely going to exist within a URL when in a web application. This is good for many reasons:

1. They’re easier to remember
2. Search engines see them as text and not garbage.
3. You can make some assumptions as to what the content is, given the key.

Use keys over (or in conjunction with) IDs. They’re nice, they’re good and you’ll love them.

More Resources

• Phil Haack recently posted a good solution to using keys (or slugs) in your MVC application. With Phil’s friendly URLs, you don’t have to sacrafice your precious integer IDs either.
• Derick Bailey had posts last summer (2009) with some thoughts on Database IDs and the storage implications. (Good comments!)

I have created enough simple projects using ASP.NET MVC with unit tests to notice a very helpful pattern. The following is a sample of a test fixture using RhinoMocks and NUnit to test a controller.

1: [TestFixture] 2: public class AdminControllerTests 3: { 4: private IFacilityRepository facilityRepository; 5: private IMeetingRepository meetingRepository; 6: private IUserSession userSession; 7:  8: [SetUp] 9: public void SetUp() 10: { 11: facilityRepository = MockRepository.GenerateMock<IFacilityRepository>(); 12: meetingRepository = MockRepository.GenerateMock<IMeetingRepository>(); 13: userSession = MockRepository.GenerateMock<IUserSession>(); 14: } 15:  16: [Test] 17: public void SaveMeeting_should_call_Add_on_MeetingRepository_if_MeetingId_is_zero() 18: { 19: // Arrange 20: var meetingData = new MeetingData { MeetingId = 0, FacilityId = 0 }; 21: meetingRepository.Stub(x => x.GetById(0)).Return(new Meeting()); 22: facilityRepository.Stub(x => x.GetById(0)).Return(new Facility()); 23: var controller = GetController(); 24:  25: // Act 26: controller.SaveMeeting(meetingData); 27:  28: // Assert 29: meetingRepository.AssertWasCalled(x => x.Add(Arg<Meeting>.Is.Anything)); 30: meetingRepository.AssertWasNotCalled(x => x.Update(Arg<Meeting>.Is.Anything)); 31: } 32:  33: [Test] 34: public void SaveMeeting_should_call_Update_on_MeetingRepository_if_MeetingId_is_not_zero() 35: { 36: // Arrange 37: var meetingData = new MeetingData { MeetingId = 1, FacilityId = 1 }; 38: meetingRepository.Stub(x => x.GetById(1)).Return(new Meeting()); 39: facilityRepository.Stub(x => x.GetById(1)).Return(new Facility()); 40: var controller = GetController(); 41:  42: // Act 43: controller.SaveMeeting(meetingData); 44:  45: // Assert 46: meetingRepository.AssertWasNotCalled(x => x.Add(Arg<Meeting>.Is.Anything)); 47: meetingRepository.AssertWasCalled(x => x.Update(Arg<Meeting>.Is.Anything)); 48: } 49:  50: private AdminController GetController() 51: { 52: return new AdminController(userSession, meetingRepository, facilityRepository); 53: } 54: }

 

The reason I’m being explicit about the term “simple” in this case is that the controller above that I’m testing doesn’t have much going on. It has some constructor dependencies (like all controllers with dependencies should), but that’s about it. The gist of the pattern is made up of three things:

1. A SetUp method, via NUnit, runs before each test to create new, fake implementations of the dependencies. In this case I’m using RhinoMocks, but you’re not limited to that (see below). Declaring them at the class level is nice, it allows you to use or ignore them at your leisure.
2. Creating the GetController() method constrains the creation of a controller to one place. This is good because your dependencies can change by adding more or removing existing dependencies. By creating one place to “new up” the controller, you only have to update one area when dependencies change instead of updating a constructor in each test. This isn’t anything new for unit testing, just a good practice.
3. Finally, your individual tests can get a new controller and stub/mock/fake the methods of your dependencies at any time during the test method and assert values or verify behavior at any time during the test.

This pattern has helped me a lot; I wish I had this in mind when I was writing lots of unit tests for controllers a year and a half ago (so I didn’t have to go back and change some of them later).

Another isolation/mocking framework I like to use is Moq. For the above example, there is a slight difference in the way the same fixture is used. The following is the same tests using Moq.

1: [TestFixture] 2: public class AdminControllerTests 3: { 4: private Mock<IFacilityRepository> facilityRepository; 5: private Mock<IMeetingRepository> meetingRepository; 6: private Mock<IUserSession> userSession; 7:  8: [SetUp] 9: public void SetUp() 10: { 11: facilityRepository = new Mock<IFacilityRepository>(); 12: meetingRepository = new Mock<IMeetingRepository>(); 13: userSession = new Mock<IUserSession>(); 14: } 15:  16: [Test] 17: public void SaveMeeting_should_call_Add_on_MeetingRepository_if_MeetingId_is_zero() 18: { 19: // Arrange 20: var meetingData = new MeetingData { MeetingId = 0, FacilityId = 0 }; 21: meetingRepository.Setup(x => x.GetById(0)).Returns(new Meeting()); 22: facilityRepository.Setup(x => x.GetById(0)).Returns(new Facility()); 23: var controller = GetController(); 24:  25: // Act 26: controller.SaveMeeting(meetingData); 27:  28: // Assert 29: meetingRepository.Verify(x => x.Add(It.IsAny<Meeting>())); 30: meetingRepository.Verify(x => x.Update(It.IsAny<Meeting>(), Times.Never())); 31: } 32:  33: [Test] 34: public void SaveMeeting_should_call_Update_on_MeetingRepository_if_MeetingId_is_not_zero() 35: { 36: // Arrange 37: var meetingData = new MeetingData { MeetingId = 1, FacilityId = 1 }; 38: meetingRepository.Setup(x => x.GetById(1)).Returns(new Meeting()); 39: facilityRepository.Setup(x => x.GetById(1)).Returns(new Facility()); 40: var controller = GetController(); 41:  42: // Act 43: controller.SaveMeeting(meetingData); 44:  45: // Assert 46: meetingRepository.Verify(x => x.Add(It.IsAny<Meeting>(), Times.Never())); 47: meetingRepository.Verify(x => x.Update(It.IsAny<Meeting>())); 48: } 49:  50: private AdminController GetController() 51: { 52: return new AdminController(userSession.Object, meetingRepository.Object, facilityRepository.Object); 53: } 54: }

Both of these examples are using the Arrange/Act/Assert (AAA) syntax. The idea is that you set up your context, run some code, then verify the results of your objects and/or system under test.

This has been a very good to me and a simple pattern for testing most controllers in many of the simple MVC applications I’ve worked.