Monday, May 16, 2011

UI Test Automation for SharePoint 2010 with Visual Studio

In this post I use a SharePoint 2010 Visual Web Part as the example. But this feature of Visual Studio can be used for any application with a UI. I’m doing a simple web part that simply adds 2 numbers together. Yes I know this is not original but it makes for a good example.
You’re required to have Visual Studio 2010 Premium or Ultimate to use Coded UI Tests
  1. Create a Visual Web Part project (don’t forget to target .Net 3.5 not 4.0)
  2. Drag 3 text boxes, 2 labels and a button on to the designer and arrange them so your web part will look similar to this:

    Add
  3. Double-click the button and add code to the event handler:

    AddCode
  4. Add a new Test Project to your solution and name it whatever you like
  5. Right-click on your new Test Project and add a Coded UI Test
  6. Click OK to accept the default choice of “Record actions, edit UI map or add assertions”

    UI Test Dialog
  7. Give it a few seconds and you will see the Coded UI Test Builder appear on the lower right

    UIMapPopUp
  8. Click the red record button
  9. Start your Visual Web Part project WITHOUT Debugging
  10. Add the Web Part to the page
  11. Put a 2 in each of the 1st 2 text boxes and click the Add button
  12. Click the Pause button on the Test Builder that has replaced the red record button
  13. Click Generate Code button (far right on the Test Builder)
  14. Give the method a name and click Add and Generate

    MethodName1
  15. Add an Assertion by dragging the Crosshairs on the Test Builder over to the last text box intended to contain the sum. As you hover over controls they will be outlined in blue. Release the Crosshairs when last text box is selected

    AssertionPoint
  16. Scroll down and select the Text property and click Add Assertion. In this case we want to make sure that our addition code is working so set the Comparison Value to 4 & the Comparator to AreEqual. Click OK. If you wish to see the test fail, you can input a different value. You can also update the code directly later in order to play with this

    AddAssertionCompComp

  17. Click the Generate Code button on the Test Builder again
  18. Give the Assertion method a name & click Add and Generate
  19. Once the code generation is complete, go back to Visual Studio’s main window and Run Tests in Current Context as seen here:

    RunTestInCurrentContext
  20. Watch the magic happen!
Depending on whether you inserted a 4 or some other value, you will see one of these 2 results:
  Passed   Failed Obviously in this example we know the code works because we saw it when we recorded it. The real value here is that if and when you change your addition code in the button click event handler, you can run this test again to see if you broke anything. Or better yet, run a test like this one along with many others you would create as part of your regression testing for the solution.

Best Practices for Coded UI Tests: http://msdn.microsoft.com/en-us/library/dd380782.aspx

Tuesday, May 10, 2011

When the Sandbox isn’t enough & a Farm solution is too much

It's really easy to just select farm solution for your Visual Studio project:



That's your choice provided that your IT department doesn't mind or your customer doesn't know any better.

But, if they do care about security, they may insist that you find a way to meet the requirements of the solution while staying in the sandbox. Trying to convince a savvy admin or an IT director that your application must be able to run at full-trust may fall on deaf ears.

A better approach to take is to identify exactly what pieces of the api you really need and offer the option of a hybrid solution. A hybrid solution allows you to develop a proxy that can expose classes to your sandboxed solution that would otherwise not be allowed. The proxy will have to be a full-trust solution. However, allowing one full-trust solution to execute in an effort to potentially keep several other applications in the sandbox is a much easier sell than doing all farm solutions all the time.

Does your assembly actually belong in the GAC?

In many cases, NO.
Many developers believe that “GACing” their assemblies is always the proper way to deploy them. In reality, privately deploying your assemblies (even if they’re strongly named) is a better option.
Assembles that are not shared by other applications should not be installed in the GAC. In fact, if only a few applications need to share it, you can still deploy privately. This provides for better isolation as well as easier upgrades via shadow copy. This is especially important with ASP.Net applications. If you install an updated assembly in to the GAC, the application pool needs to be bounced in order for the new version of the assembly to be loaded. If you deploy the new assembly to the Bin (or elsewhere), your application will finish handling in-process requests with the old version and pick up new requests with the new version. No need to restart, reset or bounce anything.

Note: If you're running a .Net version prior to .Net 2, strongly named ASP.Net assemblies must be "GACed" to avoid a locking bug.
If several applications will be sharing the assembly then GAC it for sure.