This post would cover following features of Data Explorer

• Connecting to Facebook Graph API.
• Creating a Query using current Excel Workbook's data.
• Merging two DataExplorer queries.
• Using custom formulas. 
• and finally Getting the above trend for your Facebook profile!

In this blog post I would take Seattle's neighborhood data from data.gov and land it in excel. It demonstrates the use of following features in Data Explorer

• Consuming a csv file.
• Hiding columns.
• Text Filtering.

Step1:- After you have installed "Data Explorer" add-in for Excel, click on "From File -> From CSV" link from the "Get External Data" ribbon. Below is a screenshot.n.

1. Tests are developed and tested completely in VS IDE .
2. MSTest.exe is used for running the tests in lab .

MSTest.exe is the command line test execution tool . Details about various options that it provides are here .

Mostly , MSTest.exe and VS IDE are similar . Following are some subtle differences

1. If a project has other test projects referenced , VS IDE would run tests from all the referenced projects. Whereas MSTest.exe would only execute the tests that are directly in the dll provided in command line for /testcontainer parameter.
2. VS IDE finds out all the necessary dlls required , it walks the depency graph and does this for us. MSTest.exe doesn't do this . This might result in a failure during automated runs,especially when the tests are run in remote machine using a Test Controller + Test Agent setup . Following are some solutions to this issue
1. Make sure "Copy Local" option is set for all custom dlls that are referenced.
2. Use Deployment Item option in TestSettings file to copy dlls that will not be available in the machine where tests will be run. Pass this test setting file as a parameter to MSTest.exe command line.
3. VS IDE works with relative paths .MSTest.exe won't in most cases , because design time relative path and run time relative paths would most likely be different. This issue shows up mostly for load tests.Load tests are xml files , Unit tests that are part of loadtests could be specified using relative path or using absolute path. While developing the load test with VS IDE  , it adds the tests using relative path. This may not work while running the load test from command line using MSTest.exe . Following are some possible solutions for this issue
1. Provide a placeholder location during build time (like an environment variable) , and replace it during automation run time. For example the location could be "%BuildRoot%\TestDll.dll" at design time and changed to "c:\CurrentBuild\TestDll.dll" at run time.

Update in July 2013: Visual studio 2013 preview now has the capability to execute load tests in cloud built in! Details about how to get started with cloud based load testing with Team foundation service is here.

Visual Studio provides an intuitive and straight forward way to do load testing. The integrated experience in IDE, ease with which different configurations of the test can be controlled  and the ease with which results can be interpreted is excellent. It also provides scale out, if we want to drive load from multiple machines. For intranet applications, out of the box solution works perfectly well. Setup the test rig with necessary agent machines and just start the test.

For internet facing applications, like the ones deployed in windows azure, this is a little tricky due to following reasons

1. Usually traffic from all machines inside a company goes through proxy.
   1. The proxy would have defined set of limits for outgoing request – this might interfere with load test which by definition would do lots of simultaneous requests.
   2. Since the proxy is shared, we don’t get a consistent bandwidth across multiple test runs. Consistent test bed configuration is critical for any kind of performance testing.
2. All the cloud providers charge for outgoing and incoming traffic from datacenter.

So keeping the test rig – pool of machines that drive traffic and the service close together makes sense. When they are in the same datacenter, we get standard and consistent bandwidth between those machines and the service we are trying to test.

This blog has three posts that give detailed explanation of how a test rig with Controller and Agents can be created in Windows Azure. It has everything need to get going.

Basic Idea is that we use windows azure worker roles as a simple VM, the worker role code wouldn’t actually do anything. Agent / Controller is installed and configured at role startup, after that it runs as a local windows service in the azure worker role VM. We create couple of instances of this and boom we have a test bed.

One detail here is – Visual Studio load test started out as a solution for load testing applications inside intranet. It requires all the agent machines to be part of a local network. To overcome this we use a feature called “Windows Azure Connect” . After configuring the test VM instances with “Azure Connect “ , they all become part of a local network – they would behave as if they are in local intranet. Much of this process is automatable – so setting up the rig is really quick and easy. I would love to see an OOB solution in codeplexJ .

Couple of issues that we might face with this approach

1. Connectivity from developer desktop (or a machine part of test automation) to test rig would typically be slow – it will be over internet. If the size of all referenced dlls is more than a couple of MBs , we might hit test deployment timeout issues.  Instruction for this is at an msdn forum.
2. Windows Azure updates . Windows azure reboots or even reimages the machines at least once in a month. This is to ensure that the machines have all the necessary patches and security updates installed.
   1. A reboot in the middle of a load test run would stop the run.
   2. Manual intervention would be needed after such a reboot to setup/fix the rig.

Lets see how it goes!