When I was writing ASP.NET WebForms apps, my team organized the UI layer with an MVP (Model View Presenter) pattern, preferring the Passive View variant. This allowed us to write Views that were small and lean, pulling as much logic as possible out of that untestable wasteland of UI markup and code-behind. More recently, I’ve been developing ASP.NET MVC applications (using the MVC (Model View Controller) pattern, naturally), and I like how my Views can be straightforward HTML with a few fill-in-the-blank spots for the data I want to display; much simpler to understand than the old WebForms server controls. But my most recent project, I wrote in WPF (Windows Presentation Foundation) due to some specific needs of the client, and I had to re-open the UI design pattern question. I decided on MVP, and this gave me a great opportunity to contrast the two patterns.

My goal in choosing any pattern is readable, understandable code. Even if I’m the only developer on the project, reading my own code, if six months have elapsed, it might as well have been written by someone else. Patterns inherently give structure, but more importantly, they are recognizable. Reading the code, you can spot it: “Oh! This is an MVP app. Okay, I’ll look for a Presenter class to be managing the interactions with the View. …There it is!” Future maintainers and enhancers (including your Future Self) will appreciate your consistency; patterns help you write “No Surprises” software. Both MVP and MVC meet this criterion; they are recognizable patterns, each with a distinctive fingerprint.

My secondary pattern-choosing criterion is testability: How well does this pattern let me cover every interesting part of my app with unit tests? While I see the value in integration tests and full-system tests, I’m strongly prejudiced against them. Integration tests are finicky, and full-system tests are slow. I’m unapologetically feisty about my unit tests. The better pattern is the one that not only makes it easy to test, but makes it hard to write untestable code. In other words, prefer the pattern that leads your team to fall into the “pit of success.” MVC beats MVP on this point. Let me explain.

Consider a continuum, from Untestable Scary Code to Clean, Verified Code. WebForms without the rigor of an MVP pattern, with heavy reliance on the code-behind, is far on the left of that continuum. A lot of business logic and application flow control can be hidden in the least testable layer. When you apply MVP to your WebForms app, the pattern guides you to write very slim code-behind files, with methods that are usually one line long, immediately deferring to the Presenter. This is closer to the middle of the continuum, where you can test your Presenters, provided you trust your Views to remain humble and hand over control promptly. MVC, as implemented by the ASP.NET MVC framework, gives you no code-behind files. There’s no temptation to put logic into the View because there’s hardly anywhere to put it. Control logic naturally fits in the Controller, which is a plain class you can instantiate and exercise in a unit test. The easiest path produces the cleanest result. Nice.

Why did I use MVP at all? It’s necessary in a framework that brings the View into existence first. Both WebForms and WPF start a conversation with the user by locating and instantiating a View. The View then constructs its Presenter and injects itself into it. MVC implementations start by instantiating a Controller. Unlike MVP Views, which have to talk to their Presenters, MVC Views can remain ignorant of their Controllers, and this allows them to stay logic-free and focused on rendering the UI. When using MVP, it takes vigilance to make sure your Views never do anything interesting, anything you’ll later wish you had covered with a unit test. And anything that takes vigilance is likely to drift over time.

It was fun to revisit my “old” way of structuring applications, because it made me think critically about the relative merits of MVP versus MVC. I had an instinctive feeling for which one I preferred, and comparing them helped me see explicitly that MVC increases my confidence in the correctness of my team’s code.

Make eye contact.

An Excursion into Psycholinguistics

To avoid filler words, it helps to understand why we say them, which falls under the domain of psycholinguistics.

When you and I are having a conversation, we take turns speaking, and we use a variety of verbal and non-verbal cues to signal when to switch. I’ll ask a question and then pause, and you instinctively know that it is your turn to talk. While you’re telling a story, you’ll pause periodically to see if I am following, and I will make an encouraging sound (“mm hm” or “go on”) to confirm that it is still your turn. You might say something that sparks an idea in me that I very much want to share, and the changes in my facial expression—bright eyes and an intake in breath—convey my request to have a turn. If I get these cues wrong and repeatedly speak during what you consider your turn, you will think I’m rude and interrupty.

Note that most of those transitions were signaled by a pause. To avoid being interrupted, when you need a moment to organize your thoughts but are not ready to relinquish your turn, you’ll phonate (fancy linguist term for “make noise with your speech apparatus”). You don’t have any words to say, but you want to fill the silence to retain your hold on the conversation, so you’ll use meaningless words. You’ll say “um.”

Maintaining Your Turn While Presenting

Consider how turn negotiation changes when you are presenting in front of an audience. Your instincts tell you that a pause will cause you to lose your turn, but in reality, you’re on stage. It’s your show. We in the audience have granted you an extended turn. You would feel uncomfortable in a one-on-one conversation talking for 20 minutes without exchanging turns, but it is normal, expected, and exactly appropriate during a presentation.

How do you override the unconscious desire to say “um” to maintain your turn? You make eye contact with your audience members. Deliberate, focused eye contact. Avoid scattershot scans over their heads or a fixated stare at the clock on the back wall. Instead, look at the members of your audience. Deliver a clause or a whole sentence to one person, then connect with another person for the next. Two beneficial side-effects are better reception from your audience and improved pacing in your delivery. Deliberate pauses become built in as you deliver points to different individuals.

When you make eye contact, your unconscious mind gets direct evidence that it is still your turn. You can see that there are no bids from the audience. You can feel the audience’s attention. That need to fill pauses with noise melts away.

Here’s a representative example:

bool hasMissedDeadlines = deliverables
    .Where(d => d.Deadline < _systemClock.Today)
    .Count() > 0;

I want to determine if my to-do list has any items that are late, so I use .Where() to filter my list of deliverables down to items with a deadline in the past; then I take a .Count() of the resulting list, and see if that number is greater than zero. This is a plausible solution, and our years of SQL lead us to write LINQ this way. But it can be better.

Testing “count greater than zero” is a programmer’s way of saying “are there any?” So let’s just say any. As you might expect, .Any() returns a Boolean indicating whether the collection contains any items. Further, you can pass a lambda expression to specify the predicate “any like this.” (.Count() takes a predicate, too, by the way, but I really have seen “.Where().Count()” in use, so I wanted to start from there.)

Here’s the new version:

bool hasMissedDeadlines = deliverables
   .Any(d => d.Deadline < _systemClock.Today);

In addition to being shorter, this version more directly and declaratively states my intent: “Are there any late deliverables?”

This code also executes more efficiently. For .Count() to return a value, LINQ must iterate over all items in the collection, even though I don’t care how many items there are. .Any() will return as soon as it encounters an item that satisfies the predicate. It evaluates as few items as possible, giving me an efficient and readable solution.

Or have I?

Incorporating automated tests into your Continuous Integration build process can feel similar. You’re suddenly presented with all these errors. Your product seems to be broken all the time. You liked it better when things were quiet and you didn’t know how bad it was.

There are two reasons I’m getting so many warnings from my car: It has more systems, more features, more computers than any car I’ve owned before; and it has more health sensors and warning lights. It’s better at knowing when it’s a little unhappy, and better at letting me know. I take care of these little maintenance tasks, and all is well. It never reaches the big, blow-up, throw-a-rod, leave-you-stranded, heartache-on-the-interstate meltdown that results from years of indifferent neglect.

Continuously run unit tests are an army of little health sensors. CI feels painful at first, but it pays off quickly. When the system under test wavers, even minutely, the tests catch it promptly and summon your attention while it is still a small, containable, inexpensive problem. (Provided they’re running frequently. Once a day is pretty infrequent. Strive to make them fast enough that you’re willing to run them every time you commit to source control.) Continuous Integration tests keep your problems on the scale of oil changes and tire pressure, instead of engine blocks and radiators.

I stumbled onto the solution. To explain it, I have made a video demo of MS Word’s Selection Pane feature.

On the ribbon bar, select the Page Layout tab. Look within the Arrange group, towards the right, and click the Selection Pane button. That opens the Pane, which lists all drawing objects that are on the current page.

From the Selection Pane, you can easily click the name of the item you want, and that will select it. From there, you can change formatting options or adjust its position with your keyboard.

It brings some extra features, too. Click the eye image next to an item to hide and show it, similar to Photoshop. Drag items to reorder them, which changes their z-index, bringing items in front of others.

I was so delighted when I found that button. It changed my day from one of grumbling at my mouse to calling my coworkers over to show ‘em. Enjoy!

It’s an illusion, though. I sympathize with getting taken in by that illusion. After all, I’ve owned the same cell phone for seven years—I don’t mind that it doesn’t do the latest stuff because it does everything I need (makes phone calls). To replace it, just because someone else has something shinier, sounds ridiculous. I’m the same way with cars, computers, furniture: I evaluate an item’s utility against my own needs, not something else’s capabilities. Taking the same view of your software applications can seem like good sense.

Here’s the difference with software. Factors outside your control can make your application stop working. This is especially true when it is running on a legacy operating system or a legacy language.

I just had a sharp lesson in this on one of my personal websites. My site uses a content-management system written in PHP, which I had allowed to drift a bit behind on version updates. Last weekend my webhost, quite reasonably, upgraded their servers with the latest stable version of PHP. They had notified me, so I was looking out for it, and sure enough: my site was broken. My outdated version of the content-management system was calling deprecated and discontinued PHP methods. To drive the lesson home, I was enough out of date that upgrading the content-management system wasn’t trivial, either. Here is a case where “if it ain’t broke” turned into “it’s broke anyway.”

Keeping software platforms current is not about wanting the latest features. It is about routine maintenance that keeps your critical systems comfortably supported. If you fall behind the pack, software patches and operating system upgrades offer no guarantees. That’s what it means when a technology is no longer supported: it means the manufacturer won’t be testing whether their latest change will impact that end-of-life technology. Complacency is perilous.

You might find it daunting to estimate the value of rewriting an application in a supported language. The cost is plain, but what is the return? It can sound like spending considerable time and resources to end up with the same feature set. We have helped some of our clients make such an assessment, so that they can decide when it is prudent to bring their technology stack up to date. Please get in touch if you are weighing similar trade-offs.

In order to make an informed decision, consider what it would cost to lose the application, to have it rendered non-functional—even non-starting—by an environment change. Is the application critical to your business? Is it your business’s product? What would it cost to lose it? Keeping current is insurance against that cost.

RhinoMocks, and other mocking frameworks like Moq and TypeMock, are a support structure that let you write briefer, more expressive unit tests. RhinoMocks simplifies the quick creation of fake classes that your class under test relies on and interacts with. You can use those fakes for both styles of tests; RhinoMocks can make assertions about interactions in interaction-based tests, and it can provide non-exception-throwing behavior when you just need a stand-in for your state-based tests. I listen to the language of my description to know how I want to use that Rhino Mock.

For example, your application might have an EmailDispatcher that decides which emails to send, then calls an EmailService to send the emails. You’d like to unit test the logic in the EmailDispatcher without sending thousands of real emails. This is a perfect scenario for RhinoMocks. RhinoMocks can build you a fake EmailService when your tests are running, and let you make assertions about when the EmailDispatcher calls that EmailService. RhinoMocks allows you to assert “When the EmailDispatcher is given input like this, it should call the EmailService with that info.”

Another great use for RhinoMocks is to support a class that has dependencies that aren’t interesting to the test you are writing—the class under test calls some other classes, but they aren’t relevant to the scenario you are testing. You merely need them to not be null and not throw Null Reference Exceptions when your test is running. Continuing with the above example, the EmailDispatcher could rely on a TemplateFormatter class to prepare the text of the email, but because you are writing a test fixture focusing on when emails get sent, and you are not testing how those emails are formatted, the TemplateFormatter should be as low profile in your test as possible. If TemplateFormatter is a simple class, you could just instantiate one and pass it to your EmailDispatcher under test. On the other hand, if TemplateFormatter requires its own swarm of dependencies, or if some of its operations rely on time-consuming, out-of-process dependencies like a database, replacing it with a fake class generated by RhinoMocks will keep your unit test quick and brief.

What is an example of misusing a Rhino Mock? Where RhinoMocks becomes a burden is when it over-specifies the interactions between classes. RhinoMocks can make assertions about how one class calls another, which is its power and its danger. This excessive over-specification inhibits refactoring because it entrenches the coupling between those classes—you’d want to change the internals of one class, but that would break so many tests and require tedious fixing of those tests, dissuading you from making the refactoring. Anything that makes you queasy about doing the right thing is a bad deal. From the EmailDispatcher example, I do want to test that emails are well formatted, but I don’t really care whether this is done by a TemplateFormatter, or some other class, or an EmailDispatcher method, or a private class within the EmailDispatcher, or… whatever. I don’t need to enforce the method by which the EmailDispatcher accomplishes its work, therefore I don’t want to write tests that enforce the way emails get formatted.

My rule of thumb is to tell myself, in English, what I want to verify and listen to the words I choose. Here are two examples.

“I want to test when the EmailDispatcher tells the EmailSender to send mail.” I used words that refer to testing the conditions under which one class calls another. Therefore, I’ll write an interaction-based test, using RhinoMocks’ AssertWasCalled and AssertWasNotCalled methods.

“I want to test that the result from the EmailDispatcher’s work is an email in a certain format.” Looking at the properties on the result of an operation is a good fit for state-based tests. I’ll probably still use RhinoMocks to create a fake EmailSender, since I know the EmailDispatcher is going to call the EmailSender at the end, but I am not going to make any assertions about the methods called by the EmailDispatcher.

There’s lots of great power in RhinoMocks, where it can give you just the right tool… or enough rope to hang yourself. We talk about responsible Rhino Mocking in our Agile Bootcamp, and I’ll be presenting some of the finer points of RhinoMocks at the Central Texas .NET User Group on October 13.

I admit this to you because admitting my wrongs is a step towards rehabilitation. I admit this to save you pain. Learn from my example. Test-second is so much less efficient than test-first. Consider the following workflow:

1. Reproduce, identify, debug the issue.
2. Fix the code.
3. Compile and try it out.
4. Write a test that proves I fixed it.
5. Compile and run the test.
6. Change the code back to make sure my test really proves what it is trying to prove.
7. Compile and see the test fail.
8. Re-fix the code.
9. Compile and see the test pass.

I humble myself before you. How much time am I wasting there? It’s embarrassing.

There’s also a subtle point in step 1. What if I could use unit tests instead of the debugger to find the issue? That will be faster, too.

We can do better:

1. Reproduce the issue and formulate a theory.
2. Write a test that exercises the theory.
3. Compile and see the test fail, corroborating the theory.
4. Fix the code.
5. Compile and see the test pass, validating the theory.

Perhaps you can relate. Perhaps you even bite your nails, too. I won’t judge. Flog me or join me, the comments are open: Confess your bad habits (um, your unit-testing bad habits, please), and commit yourself to improvement. I challenge you to improve your efficiency and write your unit tests first, even—especially—for the little bug fixes.