Share This Point

WSSTester is a set of two applications that can be used to automate testing of SharePoint applications. First a little background on automated testing in SharePoint……….

Testing WSS applications and web parts is a very challenging task. Most developers manually build and deploy their web parts and then open the page in a browser to test them out. This process works fine until you start doing major deployments and larger apps in WSS. Testing of interconnected components, controls, assemblies, and all their different configurations can quickly become an impossible task. Most automated web testing tools fall short almost right off the bat when it comes to testing WSS apps due to the way WSS handles authentication. Unit tests only seem to go so far when testing WSS apps since so much of their function depends on other data involved in the actual deployment. (ie Site context or list configuration)

One tool I have found that works well for testing actual deployments of WSS applications is called Watin. Watin is essentially a test harness for internet explorer that allows you to programmatically interact with the browser contents. Oh yeah and did I mention its open source too? What differs Watin from unit testing is that Watin actually looks at the output of the browser and lets you validate that output. This allows you to get a closer view of what a user would see when actually visiting the site. Another separate source forge project called Watin Recorder lets you quickly record Watin tests simply by browsing through the site. The Watin Recorder is pretty nice but it doesn’t work to well with most of the toolbars and navigation items in SharePoint because of the way they use JavaScript. You can execute JavaScript on the page but it isn’t as easy as point and click, it requires some tweaking of the c# generated by the recorder.

Soooo all this stuff is pretty cool but building and record tests for can become a big task as well if you have a lot sites and servers. Fear not, for WSSTester is here to help relieve some of the suck factor. The WSSTester solution contains two applications…

WSSTesterSiteMapBuilder – This is a little app that should be run on your WSS server. It basically generates an XML file listing all the pages on your root SharePoint site. The generated XML file can then be edited by hand to add additional pages that weren’t detected or remove pages you don’t want to test.

WSSTester – This is the main application that actually executes the tests. This application does not have to be run on the server. You load an XML file saved from the site map builder app, enter your site url and credentials and then run the tests. You can export the test results to an XML files after they are complete. Right now WSSTester only runs two simple tests on each page. It checks for the standard SharePoint web part error message and a custom error message that we have built into our web part framework that provides more detail than the standard web part errors. We render a hidden div on the page that contains details that would help a developer debug the issue and only allow the user to see a  friendly version of the error. In the future we are going to add command line support to this app so we can run tests as part of a automated build process.

You can download the source code for the WSSTester project here. You must have Watin installed first before you can compile and run WSSTester. If anyone is out there using this please provide some feedback on your experience. Disclaimer: use at your own risk!

When developing a new web part or set of web parts we build a testing site that contains every possible configuration of the web part and a solid set of test data. We save the testing site as a site template so it can be shared with other devs and installed on staging servers. This is used by the developer to test new builds of the web part and also by the automated build process to run tests after deployment. Once the testing site is complete, or when we add new pages for additional tests, we run the WSSTesterSiteMapBuilder to generate a new list of pages to test. Then after doing a new build of the web part we just run WSSTester on the testing site to determine if the new build has caused any errors.

·         Create the ability to build the list based off of pages available for a specific user.

·         Add true recursion of folders. Right now it only looks 1 level deep in document library folders because this all we initially required based on our current app design.

·         Add recursion of sites. Currently only lists pages for the root site of the collection.

·         Improve UI to allow the user to remove pages in the list without having to manually edit the xml file.

·         Add command line support.

·         Subclass the logindialoghandler to handle SharePoint forms authentication. Might be able to just record this with the test recorder.

·         Make all tests run in one browser window instance. Currently a new browser window is opened and closed for each page. Watin did not appear to be refreshing the HTML property properly after every page was finished loading. This caused the tests to run against incorrect data. Making tests run in one browser instance will greatly increase the speed.

·         Add tests for Service unavailable, 404, and 401 errors.

·         Add tests to detect redirection to the standard WSS error page and other standard types of errors.

·         Research creating tests that can compare a checksum or hash of a previous version of the page to the current one. Will have to be able to deal with dynamic control id’s generated by asp.net.

-Mark