Checklist for Testing SharePoint Web Parts

  • Article

 

Lana Fly
Susan Harney
Microsoft Corporation

November 2004

Applies to:
    Microsoft Windows SharePoint Services
    Microsoft Office SharePoint Portal Server 2003

Summary: Use this checklist to assist with the deployment and maintenance of Microsoft SharePoint Products and Technologies Web Parts. (11 printed pages)

Contents

Introduction
Task Checklist for Testing Web Parts
Conclusion
Additional Resources

Introduction

If you install and maintain the Web Parts for your Microsoft Office SharePoint Portal Server portal site or Microsoft Windows SharePoint Services team site, you should help ensure that the Web Parts are secure, well-written, and can integrate appropriately with other components on the Web Part Page.

By understanding the tasks we describe in this article, you can determine whether a Web Part meets these requirements, and help enhance the success of your Web Part deployment and maintenance.

Note   For more information about authoring Web Parts that meet these criteria, see Best Practices for Creating Web Parts for Microsoft SharePoint Products and Technologies.

Task Checklist for Testing Web Parts

The following checklist contains a series of tasks designed to help you determine the quality of Web Parts you are asked to deploy or maintain.

For details about how to perform these verifications, click the Go to steps link that follows each list item.

Task Checklist

Task  
      Verify that you can add the Web Part properly to a Web Part zone. Go to steps.
      Verify that static Web Parts render appropriately and do not cause the Web Part Page to fail. Go to steps.
      Verify that the Web Part works correctly regardless of where the Web Part Page is located. Go to steps.
      Verify that property attributes are correctly defined. Go to steps.
      Verify that Web Part changes made in personal view are not reflected in shared view. Go to steps.
      Verify that every public property can handle bad input. Go to steps.
      Verify that the Web Part handles all of its exceptions. Go to steps.
      Verify that the Web Part renders correctly in Microsoft Office FrontPage. Go to steps.
      Verify that Web Part properties displayed in the tool pane are user-friendly. Go to steps.
      Verify that the Web Part appears appropriately in the search results. Go to steps.
      Verify that you can import and export the Web Part properly. Go to steps.
      Verify that the Web Part previews properly. Go to steps.
      Verify that the Web Part can access its resources in different setup configurations. Go to steps.
      Verify that Web Part properties are not dependent on each other. Go to steps.
      Verify that Web Parts work correctly with different combinations of Web Part zone settings. Go to steps.
      Verify that the Web Part renders appropriately based on user permissions. Go to steps.
      Verify that adding several instances of the same Web Part to a Web Part Page (or in the same Web Part zone) works correctly. Go to steps.
      Verify that Web Part caching works correctly. Go to steps.
      Verify that requests to other HTTP sites or Web services are asynchronous. Go to steps.

Verify that you can add the Web Part properly to a Web Part zone.

Adding a Web Part to a Web Part zone is the most common user task. Therefore, it is essential that the Web Part works correctly to create a good user experience.

To test

  1. Create a new Web Part Page.
  2. Click Modify Shared Page, click Add Web Parts, and then click Import.
  3. Import the .dwp file for your Web Part.
  4. Add the Web Part to a Web Part zone.

Verify that static Web Parts render appropriately and do not cause the Web Part Page to fail.

Web Parts that are placed outside of a Web Part zone, or static Web Parts, are contained in .aspx pages, but not in the Web Part zone. Because the static Web Part is a Web form control, ASP.NET renders the Web Part. You cannot save changes in either shared or personal view.

To test

  1. Open FrontPage.

  2. Create a new blank page.

  3. In Design view, on the Data menu, click Insert Web Part.

  4. From the Web Part Gallery that appears in the task pane, drag a Web Part onto the page.

  5. Save the page as an .aspx page.

  6. View the page in the browser.

    Note

       

    Make sure that your Web Part is within the

    <form >

    tags.

  7. Verify that the part renders correctly (for example, you should not be able to save changes in a static Web Part).

Verify that the Web Part works correctly regardless of where the Web Part Page is located.

You can add Web Parts to Web Part Pages that are contained in a document library as well as Web Part Pages that are contained in the top-level Web site. They should work correctly in either location.

To test

  1. Create a Web Part Page in a document library.
    • Browse to the portal site.
    • On the Create menu, click Web Part Page.
    • In the New Web Part Page creation form, Save Location lists the document libraries in which the Web Part can be saved. Select a document library, and then click Create.
    • Import your Web Part from the gallery.
  2. Create a Web Part Page in the top-level Web site.
    • Open a SharePoint site in FrontPage.
    • On the File menu, click New.
    • In the New Page section of the task pane, click More page templates, and on the Web Part Pages tab, select a template.
    • Click on a zone to bring up the gallery (or on the Data menu, click Insert Web Part), and then import your Web Part into a zone.
    • Save the Web Part Page in the top-level Web site, for example, at the same location where the default.aspx is located.

Verify that property attributes are correctly defined.

You can specify Web Part properties in two ways: as an XML BLOB contained within the Web Part, or as an attribute within the Web Part.

Because of how the Web Part infrastructure handles property values, we recommend that you define properties as simple types rather than as complex types so that they work properly if specified as attributes of the Web Part.

To test

  1. Create a static Web Part in FrontPage and, in Code view, try setting every property the Web Part has as an attribute.
  2. Browse to the page and see if the page fails or if the property was ignored.

Verify that Web Part changes made in personal view are not reflected in shared view.

Changes made in shared view are seen by all users. Changes made in personal view should only be seen by the person that made them.

To test

  1. Add the Web Part in shared view.
  2. Edit the properties in shared view.
  3. Change to personal view.
  4. Edit the property in personal view.
  5. Change back to shared view, and then make sure the Web Part does not use any of the values changed while in personal view.

Verify that every public property can handle bad input.

As for any ASP.NET control or application, you should validate all user input before performing operations with it. This validation can help to protect against not only accidental misuse, but also deliberate attacks such as SQL injection, cross-site scripting, buffer overflow, and so on.

To test

  1. Verify that the Web Part can detect invalid input for properties and that it informs the end user that bad data was entered.
  2. Verify that the property is not used outside of its intended purpose. For example, if a Web Part is intended to allow users to link URLs, limit the protocol usage to HTTP instead of allowing any protocol to be saved (for example, javascript://).
  3. Verify that the Web Part HTML encodes the property value when rendering user input to the client.

Check all the ways in which property values can be changed, including:

  • Modifying the .dwp file in a text editor.
  • Modifying properties in the tool pane.
  • Modifying properties in Code view in FrontPage.
  • Using the Web Part Page Services Component (WPSC), which is a client-side object model that provides a way to set properties and persist them from the client browser.

Verify that the Web Part handles all of its exceptions.

A Web Part should handle all exceptions rather than risk the possibility of causing the Web Part Page to stop responding.

To test

Enter error and boundary cases for Web Part properties to verify that the Web Part never breaks the page by not catching one of its own exceptions.

Verify that the Web Part renders correctly in Microsoft Office FrontPage.

If your organization is using FrontPage to customize SharePoint sites, verify that the Web Part renders properly within FrontPage. To accomplish this, the Web Part developer must implement the IDesignTimeHtmlProvider interface.

To test

Open up a Web Part Page that contains the Web Part in Design view in FrontPage. Verify that the Web Part renders correctly and you do not see the message "There is no preview available for this part."

Verify that Web Part properties displayed in the tool pane are user-friendly.

Because the tool pane is where users modify Web Part properties, it is important that users can work with Web Part properties easily in it.

To test

  1. Add the Web Part to a Web Part Page. Click Modify Shared Page, click Modify Shared Web Parts, and then select your Web Part. The tool pane should appear and display the Web Part properties.

  2. Verify that the Friendly Name is easy to understand, for example, a property named MyText should be My Text (notice the space between the two words).

  3. Make sure the Description (the ToolTip that appears) helps the user understand how and why to set the property.

  4. Verify that the Category name makes sense. (Miscellaneous is used when no category is specified for the property, but it is not especially helpful to the user.)

  5. Verify that the order of the properties makes sense.

  6. If appropriate, check that these properties are localized using the following method:

    After installing the SharePoint language packs, create a new subsite and select a different language. Add the Web Part to a Web Part Page in the new subsite and verify that Friendly Name, Description, and Category are localized in the tool pane.

Verify that the Web Part appears appropriately in the search results.

Because Web Part galleries can contain numerous custom Web Parts, the search capability helps users quickly find the Web Parts they want.

The Web Part infrastructure uses the Title and Description properties of the Web Part to build the result set, so comprehensive information in these fields results in easily searchable Web Parts.

To test

  1. Add the Web Part to the Site Web Part Gallery by navigating to Site Settings, clicking Go to Site Administration, clicking Manage Web Part Gallery, and then clicking New Web Part.
  2. Choose the Web Part you're testing, and then click Populate Gallery.
  3. Browse to a Web Part Page, and then click Modify Shared Page, click Add Web Parts, and then click Search. Enter the appropriate search text and click Go. The Web Part should appear as one of the top choices.

Verify that you can import and export the Web Part properly.

By default, whenever you export a Web Part, each Web Part property is included in the .dwp file. However, because properties can contain sensitive information, for example, a date of birth, you can identify a property as controlled, allowing you or the user to exclude the value if the Web Part is exported. Only properties that are exported when the user is in personal view can be controlled; in shared view, all property values are exported.

To test

  1. Add a Web Part from the gallery into a Web Part Page and set the Web Part's properties.
  2. On the Web Part chrome drop-down menu, click Export to export the Web Part.
  3. Save the .dwp generated onto your local computer, and re-import the Web Part by clicking Modify Shared Page, clicking Add Web Parts, and then clicking Import.
  4. Browse to the .dwp file, click Upload, and then click Import.
  5. Make sure that the properties that were exported are correctly imported.
  6. Verify that any property that would not make sense to export (for example, a Social Security number) has the ExportControlledProperties attribute set. (The Allow Export Sensitive Properties check box in the tool pane should be cleared.)

Verify that the Web Part previews properly.

It is important to create previews for Web Parts so that administrators are able to review the parts included in the Web Part gallery.

To test

  1. Go to Site Settings, click Go to Site Administration, click Manage Web Part Gallery, and then click the Web Part. The preview should render.
  2. Verify that there are no script errors.
  3. Verify that the preview appears correctly.

Verify that the Web Part can access its resources in different setup configurations.

Web Part resources cannot be part of the DLL because they must be URL-accessible. Examples of these resources are images, .js files, or .aspx pages.

To test

Note   Because a Web Part assembly can be installed in either the bin directory (

<%SystemDrive%>\Inetpub\wwwroot\bin

), or the global assembly cache, you must go through each of these test steps with the Web Part installed in the bin and again with the Web Part installed in the global assembly cache.

Add the Web Part to your page in all the following scenarios and make sure that it can correctly access its resources:

  • Add the Web Part to the top-level Web site.
  • Add the Web Part to a subsite with unique permissions, in which the user only has rights in the subsite.
  • Add the Web Part to a Web Part Page inside a folder in a document library.
  • Add a Web Part to a site with Self-Service Site Creation enabled on the virtual server.
  • Add a Web Part to a site with Host Header mode enabled.
  • Add the Web part to a site where the top-level Web site is not a SharePoint site, for example, http://servername/customURL.
  • Add to the Web Part to Web Part Pages that are in different subsite languages.

Verify that Web Part properties are not dependent on each other.

Because you cannot guarantee the order that properties are set in the tool pane, you should avoid writing Web Part properties that are dependent on each other.

To test

  1. Test different values for properties in the tool pane.

    Note   If a property is not visible in the UI, or is disabled, you can open the Web Part Page in FrontPage, switch to Code view, and then set the properties by editing the XML. Export the Web Part, save the .dwp file, and then modify the .dwp file.

  2. Import the .dwp file back into the page and check the property values.

Verify that the Web Part works correctly with different combinations of Web Part zone settings.

Web Part zones have properties that control whether a user can persist changes. If a user attempts to save changes to a Web Part without the correct permissions, a broken page can result.

The following Web Part zone properties affect Web Parts in the zone:

  • AllowCustomization If false, and a user is viewing the page in shared view, the Web Part cannot persist any changes to the database.
  • AllowPersonalization If false, and a user is viewing the page in personal view, the Web Part cannot persist any changes to the database.
  • LockLayout If true, changes to the AllowRemove, AllowZoneChange, Height, IsIncluded, IsVisible, PartOrder, Width, and ZoneID properties are not persisted to the database regardless of view.

To test

  1. Create a page in the browser, and then add your Web Part into several zones, both in shared and personal views.
  2. Open FrontPage. Open a Web Part Page on a SharePoint site and, in Design view, double-click a Web Part zone (or right-click over a Web Part zone, and then on the shortcut menu, click Web Part Zone Properties), and then change the zone properties. Alternatively, you can switch to Code view and type in the attributes for the Web Part zone control.
  3. View the page in the browser.
  4. Verify that the part does not break the page and functions correctly.
  5. Verify that any UI displayed in the Web Part indicates to the user that changes cannot be persisted or that UI is disabled as appropriate for the zone settings.

Verify that the Web Part renders appropriately based on user permissions.

Because a Web Part is managed by the user at run time, the Web Part should render with a user interface that is appropriate for each user's permissions.

To test

  1. Test with different User accounts that have only Reader or Contributor rights.
  2. Make sure the UI is suppressed if the end user does not have permissions to perform a certain action. (For example, if a Web Part displays a Save button, it should be disabled or hidden if the user does not have permissions to perform that action.)
  3. Turn on anonymous access for the site and browse a Web Part Page that has your Web Part, but make sure the sign-in button is still visible on the page. (When the sign-in button is displayed on the page, the user has not yet been authenticated.)

Verify that adding several instances of the same Web Part to a Web Part Page (or in the same Web Part zone) works correctly.

When you want multiple Web Parts to share client-side script, you should place the script in an external file and register the script for the page to improve performance and simplify maintenance.

To test

  1. Add several instances of the Web Part to the page. Be sure to execute any client-side script that is specific to the Web Part.
  2. Add several instances of the Web Part to the same Web Part zone. Be sure to execute any client-side script that is specific to the Web Part.

Verify that Web Part caching works correctly.

For any operation that works with a large amount of data, use a Web Part cache to store property values and to expedite data retrieval.

Web Part authors can choose to cache data in several ways, but ultimately the administrator decides the type of caching that a Web Part uses.

Following are the three types of cache:

  • None, which disables caching.
  • Database, which uses the content database (and requires all objects to be serialized).
  • CacheObject, which uses the ASP.NET Cache object (the default).

To test

You set the type of cache using the value of the WebPartCache element in the web.config file.

  1. In the web.config file, change the <WebPartCache Storage="CacheObject"> statement to <WebPartCache Storage="Database">, and make sure that the Web Part still works correctly.

  2. Change the statement to <WebPartCache Storage="None">, and then make sure that the Web Part still works correctly.

    Note   By default, exceptions related to caching are not displayed by the Web Part infrastructure. For debugging purposes only, you can make the following changes to your web.config file.

    In the <system.web> tag, locate the <customErrors mode="On"> tag and change it to <customErrors mode="Off"> to see the ASP.NET exception when an error occurs instead of being redirected to the error page.

    In the <SharePoint> tag, locate the <SafeMode MaxControls="50" CallStack="false"/> tag and change it to <SafeMode MaxControls="50" CallStack="true"/>. This causes the ASP.NET error message to display with stack trace information.

Verify that requests to other HTTP sites or Web services are asynchronous.

For performance reasons, you should use an asynchronous thread for any operation that works with a large amount of data.

To test

  1. Check with the developer to see if she or he is making any calls to Web services or other HTTP sites. Confirm that the calls are asynchronous.
  2. Run some performance tests on a page with the Web Part.

Conclusion

Web Parts are key elements of Microsoft SharePoint Products and Technologies. By using the guidelines described in this article, you can help ensure that the Web Parts you are responsible for are secure, well-written, and integrate well with other components on the page.

Additional Resources

Deployment center information

Microsoft Windows SharePoint Services Deployment Center

Microsoft Office SharePoint Portal Server Deployment Center

Articles

Packaging and Deploying Web Part for Microsoft Windows SharePoint Services

Using Wppackager to Package and Deploy Web Parts for Microsoft SharePoint Products and Technologies

Best Practices for Creating Web Parts for Microsoft SharePoint Products and Technologies