Virtual Bartender

Hey, anyone else see this in the September Popular Science magazine?

Online beverage management, password-protected (stay out of the alcohol, kids!), and fully automated. My kind of drinking.

The Virtual Bartender

I Love Google!

I don't say this very often because - quite frankly - I'm hardly ever this impressed, but: I love Google! Everything they do seems to be cooler and cooler.

So of course they started out with the search engine, then GMail (with links to Calendar, Docs, etc.), then whatever other various cool things they've done that I haven't found out about yet... I even host my personal domain email (jesschadwick.com) with their "Google Apps" service - beautiful! So, when I recently went searching for a new place to call home to my personal blog, I came across Blogger/BlogSpot. I'm no historian - and to be honest I haven't done any research on the fact so I can't be sure - but from things I've read it seems like Google just bought the Blogspot service to add to its repertoire of awesomeness. Does that make it any less cool? No, because the fact is that it still has that Google feel to it. You know - simple, slick, easy-to-use, and quick. Oh, and did I mention customizable?

I'll 'fess up right now: once I found out that Blogger.com was a Google property, I stopped my search then and there (of course I took a walk through it first, but it pleased me just as I thought it would) so I'm not entirely privvy to all of the cool free blog sites out there, but the main thing that got me about Blogger.com (after the ad-free interface) was the depth of customization it offered. And right in the admin UI, too. It's just plain awesome.

I've got nothing but respect for Google. If Google was a woman, she'd be the hottest supermodel ever.

Dummy Page Handler

My current project at Infragistics is revamping our entire redirect and tracking backend. Since we are dealing with redirects and rewrites, my tests naturally ventured into the realm of doing something to/with the current HttpContext. As anyone who's dealt with this can attest to, I had my fair share of difficulties along this road, but decided to blog about one problem and solution I thought might be particularly interesting and/or useful for anyone testing redirects.

My situation

I have a list of request URLs along with a corresponding redirect path for each of them. The project I'm working on is a library - it's meant to be used in a web site, but is not actually run as a standalone site. You can unit test with your favorite framework all you want, but at some point when you're dealing with redirection and the HttpContext, you're eventually going to want to try it out in a hosted environment. Using blog posts and code from Scott Hanselman and Paul Haack, I set myself up a nice little WebDev process and ran my integration tests within that. Everything worked great, except... RED BAR?!?

My redirection tests had failed. "404 Error" messages filled my Output box. Oh... yeah - using the hosted approach actually creates a website using physical files, just like any normal website. The fact that my integration test class library was the thing starting it up was irrelevant - it still expected the physical pages to exist and it wouldn't allow me to just redirect to any hypothetical path that I wanted to (even though my tests didn't really care whether the destination path actually existed or not - just that our response was redirected properly).

(Note: If you're not partial to my storytelling, you can just jump down to the Solution section below for what I eventually came up with.)

My first attempt at was a knee-jerk reaction: WebDev wanted a physical file? I'll give it one. So, I added "dummy.html" to my project and used TestWebServer.ExtractResource("dummy.html", destinationPath) before every request. Echk. This approach gave me a few reasons to feel uneasy: I now have an extra (rather meaningless) static file around to clutter up my project; I'm writing a file before EVERY request; and well, what if sometimes I actually wanted the 404 error to occur?

Onto attempt #2. Well, let's call it Attempt 1.1, because I didn't actually solve either of the last two issues, but that stupid extra file in my project was bugging me, so I replaced the call to ExtractResource("dummy.html", destinationPath) with CreateDummyPage(destinationPath). The CreateDummyPage() method did away with reading the dummy HTML page from the resources and just used a StringBuilder to populate the content... then wrote it to a file. But, like I said - this didn't really help fix my two other issues.

Solution

The solution ended up being ridiculously easy: write an HttpHandler to serve up dummy pages. The code ended up looking like below. Of course, you can boil this code down even more and simply use a string constant for the page content. But, as you can see, I wanted some kind of content on the page (to make sure the Handler itself was actually working, at the very least!).

using System;

using System.Text;

using System.Web;

namespace Infragistics.Guidance.Web

public class DummyPageServer : IHttpHandler

{

private string _PageTitle = "Dummy Web Page";

public bool IsReusable

{

get { return true; }

}

public void ProcessRequest(HttpContext context)

{

string body = String.Format("Requested path: {0}", context.Request.Path);

StringBuilder sb = new StringBuilder("<html>");

sb.AppendFormat("<head><title>{0}</title></head>", _PageTitle);

sb.AppendFormat("<body>{0}</body>", body);

sb.Append("</html>");

context.Response.ClearContent();

context.Response.Write(sb.ToString());

context.Response.End();

}

}

}

Then, you register the module like so:

Oh, but wait - what about my third concern from before? What if I don't want every .aspx request to be mocked up?? Just be more specific in the handler definitions, such as:

This approach seems to be working great for all of my tests so far. No more 404's - yay! I hope it can help with yours.

NUnit and MSTest working in harmony

For my latest project at Infragistics, we decided it would be prudent to take the TDD approach. We do all our development in Visual Studio 2005, however most of us do not have the Team System edition and are left without the MSBuild/MSTest framework it provides. Those of us without VS2k5: TS who want to try our hand at TDD have to find another suitable framework and - as anyone who has ever searched for .NET unit testing knows - the natural course of Googling will inevitably bring you to NUnit. During a discussion about which testing framework to "standardize" on in our group, Ambrose came across this MSDN Magazine article which - in addition to being an informative article overall - has a great tidbit about writing tests that work under both NUnit and MSTest. And, like any great tip, it's incredibly simple and boils down to defining aliases for the various attributes you use. A little more searching, and I found this complimentary blog entry that sheds a little more light on just what attributes match up together.

Unfortunately, choosing to go this route means that you're limited to the lowest common denominator when it comes to what attributes and Asserts you can use (at least without having to add "#if NUNIT" directives everywhere), but when you're looking for a cross-test-platform solution like we were, it's a pretty good compromise!