Quick Setup for Testing Explorer in a Virtual Machine

We need to know our users in order to build effective software for them, but we can sometimes have blind spots. As tech professionals, we use the best tools available, but we sometimes fail to adequately consider the platforms and hardware used by our audience. Then the bug report comes in, complete with a totally unrecognizable screenshot. What is THAT? That’s what the fruit of your labor looks like on IE…

Testing Internet Explorer is an oft-forgotten step in software development, but if that’s where the users are, that’s where the testing needs to happen. There are lots of ways to test on different platforms, each with a different balance of power and convenience. Lately I’ve had to track down some nasty IE JavaScript bugs, so I’ve been running a Windows virtual machine on my MacBook.

It’s not perfect, but it’s the best I’ve got for now. Here’s how it works.

Creating the VM

My Virtual Machine host of choice is Virtual Box, and installation is relatively painless.

Once you have VirtualBox installed, you’ll need a virtual machine image. Microsoft offers a selection of images for various platforms, with browser versions going back to IE 8. (I chose IE10 on Win7 based on project requirements.)

These machines come with trial versions of Windows, and those trials expire after 90 days. Microsoft suggests making a snapshot before you first start up the VM, which should allow you to roll back and re-start the trial. Of course, you’ll lose any files or settings stored in the VM at that point, so let’s all meet back here in three months, OK?

When you’ve downloaded and unzipped the VM from Microsoft, you’ll find two files: an .ovf file and a .vmdk file. The .ovf file contains the virtual machine configuration, while the .vmdk is the disk file.

To import the VM image, select Import Appliance from the File menu in VirtualBox, and navigate to the .ovf file. Click through the wizard, and you’re almost ready to run Windows! Here are some instructions from Oracle.

Updating VM Settings

1. Take a Snapshot – Toggle from Details to Snapshots in the upper right, and take a snapshot first.
2. Base Memory – Find this setting under System and boost the RAM to at least 2G. The more the merrier, but don’t starve your host machine. (under System)
3. Video Memory – Increase it to 128MB under Display.
4. Shared Folders – It’s nice to be able to move snippets, logs, etc. between the host and VM. I don’t have anything really long-lived that I want to share between the environments, so I just share my Desktop. Set auto-mount to true so it gets a drive letter.
5. Clipboard – Without this, you’ll end up typing every URL from scratch, like I did for the first day. Select the Advanced tab under General and choose Bidirectional for the shared clipboard.

Inside the VM

The main trick here is connecting to your local development environment. I like to point the VM’s localhost at my laptop so I can simply copy my links (e.g. http://localhost:3000) from my main browser into Internet Explorer on the VM. Here’s how to make that work:

1. Open the start menu and type cmd to find the command-line shell. Right click it, and choose ‘Run as administrator’.
2. Figure out where your hosts file lives. Usually it’ll be C:\windows\system32\drivers\etc\hosts.
3. Open the hosts file with notepad from your administrator console, e.g. notepad C:\Windows\system32\drivers\etc\hosts
4. The default VirtualBox NAT configuration maps the host machine to 10.0.2.2. To map that to localhost, just enter localhost 10.0.2.2 at the bottom of the file` and save it.
5. Clear your dns cache with ipconfig /flushdns and restart any open web browsers.
6. Test away!

Doing the Work

So you’re inside your Windows VM, running IE and coming to terms with broken layouts and JavaScript. What next? You can open developer tools through the menu or with F12, but there are some additional things to be aware of (aside from remembering to use Ctrl for copy and paste shortcuts):

• Cache: IE’s caching behavior can be intractable and demoralizing. The dev tools include a cache menu, where you can ask IE to clear cache and always fetch files from the server. You can also enter ‘In Private’ browsing mode from the Safety menu. If you’re dealing with source files that have the same path, but differ in query string or live on different servers, the source code viewer may lie to you and show you the first one it saw rather that the active version. I’ve found that once you actually Start Debugging, the files are refreshed with the code that’s actually running.

• Minified Sources: These older dev tools won’t read sourcemaps or prettify your compressed libraries, so use un-minified development versions whenever possible.
• XDomainRequest: If you use this API in your code or via a library, gotchas abound. Headers such as content type don’t behave well, which can break the request parsing code you’ve come to rely on in your framework. XDomainRequest also won’t send requests from one protocol to another, even from an http page to an https endpoint. I found this post to be a valuable resource.