Simulate a Mobile Browser using Chrome

When I first started down the road of mobile Web development, I asked around, Googled, and found some wacky, some nice mobile browser simulators that various enterprising individuals slapped together.  Then I discovered that the easiest way to simulate a mobile browser was right in front of my face.  If you already use Chrome, you're just a step away.  All you need to do is override the "User Agent" to instruct the browser to use an agent specific to a device, either by selecting it from a list, or entering the user agent string directly.  Steps:

0. Get Chrome if you don't already have it

1. Click the wrench icon on the top right

2. Goto Tools -> Developer Tools

3. Click the gear icon on the bottom right

4. Find the setting "Override User Agent", check it, and select the browser/device you want to emulate

5. Refresh your page and inspect it.  This is how it will look on the device you chose.  (You'll have to re-size the browser to a phone-ish size if you've selected a mobile phone device)

Don't see the user agent string you're looking for in the list?  Look here (http://www.useragentstring.com/pages/useragentstring.php) for an extensive list of user agent strings you can copy and paste into the free-form textbox.

Instant MVC 3 Mobile App

Have you been pondering getting into mobile development, but have been procrastinating, and making excuses to yourself about how little time you'll have to devote to it, the steep learning curve, etc?  Yeah, me too.  That is, until I found the simple but awesome "Mobile Ready HTML5" template using Visual Studio Extension manager.  Its a fully functioning MVC 3 application template that is "mobile ready" out of the box, and allows you to easily create your own mobile views for a new or existing MVC 3 app.

The elegant key to its functionality is the subclassing of the System.Web.Mvc.RazorViewEngine, overriding the "FindView" method (Figure 1), and deciding on which View to serve up based on the browser type.  This prevents having to change any code in your controllers, keeping things clean.

Figure 1

using System.Web.Mvc;

namespace Web
{
    class MobileViewEngine : RazorViewEngine
    {
        public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
        {
            ViewEngineResult result = null;
            var request = controllerContext.HttpContext.Request;

            //Determine if this is a mobile browser
            //IsSupportedMobileDevice is an extension method which queries the UserAgent
            if (request.IsSupportedMobileDevice() && ApplicationHelper.HasMobileSpecificViews)
            {
                //Get mobile view
                string viewPathAndName = ApplicationHelper.MobileViewsDirectoryName + viewName;
                result = base.FindView(controllerContext, viewPathAndName, masterName, true);
                if (result == null || result.View == null)
                {
                    result = base.FindView(controllerContext, viewPathAndName, masterName, false);
                }
            }
            else
            {
                result = base.FindView(controllerContext, viewName, masterName, useCache);
            }
            return result;
        }
    }
}

To create your mobile views, you'll simply need to create a folder called "Mobile" (or anything else, as it's configurable) under the existing Views folder, like so:

It's all downhill from there. I made a couple changes and additions to the UserAgent check, but aside from that, this template will have you up and running with an MVC 3 mobile app in no time.

To get it from Visual Studio:
1. Open extension manager from Tools/Extension Manager
2. Goto Online Gallery, and search for "Mobile Ready HTML5"
3. Click Download.

To get it from a browser:
Go here: http://visualstudiogallery.msdn.microsoft.com/9df9c61c-4d90-43e5-9aa1-a58786b7a1e4.

Thanks to Sammy Ageil for putting this together.  He's got some more details and instructions on his site: http://www.sammyageil.com.

Using Moq for Unit Testing

Unit tests should be run in isolation. Meaning, a test method should not have to rely on database connections or other external dependencies being available. To accomplish this, the repository (or other data access) class used by a service must be mocked and injected using the service constructor.  Review this sample code:

[TestMethod]
public void GetByID_Test()
{
    var orderCode = "TestOrder";

    //Create a mock repository, and specify that the GetByID method always 
    //returns an Order object with a given order code
    var mock = new Mock<IOrderRepository>();

    mock.Setup(m => m.GetByID(It.IsAny<int>())).Returns
    (
        new Company.DataAccess.Order{OrderCode = orderCode}
    );

    //Inject the mock repository into the service using constructor
    var orderService = new OrderService(mock.Object);

    //Call the service method
    var order = orderService.GetById(4);

    Assert.AreEqual(order.OrderCode, orderCode, 
        string.Format("OrderCode {0} doesn't match the expected value {1}", order.OrderCode, orderCode));
}

All this code is doing is creating a "fake" repository using the interface, then setting up the method used by the "GetByID" service method that always returns the same value.  If desired, methods can be faked to return different values based on the parameter passed in.  Ideally, the mock repository setup would be contained in a common setup method, and each and every repository method would be setup with expected values, so it could be reused in each test method.

Yes, this adds time to your development cycle, but it makes your test methods more precise, isolating only the code it's meant to test, eliminating reliance on dependencies such as databases and any other "external" dependency.

To download and read more on Moq: http://code.google.com/p/moq

Unit Testing Guidelines

As quality-conscious software engineers, we all (hopefully) do some level of unit testing.  This typically ranges from simply running your code to see if it works, up to full-blown test-driven development in which the component coding cannot commence until all positive and negative unit tests are thoroughly completed.  If you fall towards the bottom of the range, your QA team probably hates you, and if you are closer to the top of the range, well, uh, honestly, your QA probably still hates you.  Either way, if you create any level of unit tests, there are some basic guidelines that should be followed.  These are the guidelines I like to follow.  If you don't have a set of "rules of thumb" for your team, here's a good place to start......

General Rules:

• At least one test method should be written for every public service method and every new or overridden repository method
• Where applicable, positive and negative tests should be written
• Every Assert should include a relevant, meaningful error message for when failure occurs
• The Arrange, Act, Assert pattern should always be followed (see below)

There's no need to re-hash what others have written better than I can, so, please read this article on MSDN: Guidelines forTest-Driven Development.  If you don't want to delve into that heavy reading, one important (must-read) highlight from that article is that a good unit test has the following characteristics:

• Runs fast, runs fast, runs fast. If the tests are slow, they will not be run often.
• Separates or simulates environmental dependencies such as databases, file systems, networks, queues, and so on. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
• Is very limited in scope. If the test fails, it's obvious where to look for the problem. Use few Assert calls so that the offending code is obvious. It's important to only test one thing in a single test.
• Runs and passes in isolation. If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests. Change them for simplicity and reliability. Tests should run and pass on any machine. The "works on my box" excuse doesn't work.
• Often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces. We are accomplishing this by using the Moq mocking framework.
• Clearly reveals its intention. Another developer can look at the test and understand what is expected of the production code.

Arrange, Act, Assert:

Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As.

• Arrange is variable declaration and initialization.
• Act is invoking the code under test.
• Assert is using the Assert.* methods to verify that expectations were met. Following this pattern consistently makes it easy to revisit test code.

Example:

[TestMethod]
public void should_be_able_to_add_two_numbers_together()
{
    // Arrange
    int firstNumber = 1;
    int secondNumber = 2;
    Calculator calculator = new Calculator();

    // Act
    var result = calculator.Add(firstNumber, secondNumber);

    //Assert
    result.ShouldEqual(3);
}

This makes it much easier to see:

• What is being set up and initialized in the arrange section
• What method is being executed in the act section
• What determines the outcome of the test in the assert section

This pattern becomes even more important when using a mocking framework, which we will be doing, using Moq, which I'll describe in my next post.

Share your PowerPoint Presentation using Google Docs

You use PowerPoint, and love it, but (believe it or not), many people don't.  So, how do you go about sharing your presentation with everyone, regardless of what they have (or don't have) installed on their PC?  There are a few ways to accomplish this.  One way is to create a free account with a site such as SlidePoint  (http://www.slidepoint.net), which provides software for you to convert your ppt/pptx files into their proprietary format then upload and share publicly.  However, since I'm a Google fan, I'm going to walk you through uploading and sharing a PowerPoint presentation using Google Docs.  It's very straightforward:

1. Goto http://docs.google.com
2. On the top left, click on the "upload" button, just to the right of the "Create" button, then select "Files..."
3. Find and select your PowerPoint file (.ppt/pptx)
4. You'll be presented with an "Upload settings" dialog.  Leave the settings as is
5. Click "Start upload"
6. Wait while the file is uploaded - you should see a status on the lower-left corner
7. The file will now show up in your document list.  Click on it to open.
8. Click the blue "Share" button in the top-right corner
9. Under "Who has access", click the "Change..." link next to "Private - Only ...."
10. Select "Public on the web", and hit save
11. The link to share with others is in the "Link to share" textbox
12. Click "Done".  Your presentation is now shared to anyone with an Internet connection.