Programming Microsoft ASP.NET 4 - Dino Esposito [192]
siteMapFile="default.sitemap" /> siteMapFile="fr.sitemap" /> ... siteMapFile="it.sitemap" />
Essentially, you have multiple providers of the same type—XmlSiteMapProvider—but working on distinct site map files. When you access site map information programmatically, you can specify which site map you want to use. (I’ll say more about this in a moment.)
Note
You use .resx files as previously discussed to localize site maps as long as you’re using the default provider and the XML .sitemap provider. If you use a custom provider, say a database-driven provider, you’re totally responsible for setting up a localization mechanism.
Testing the Page
More often than not, Web sites are planned and created by developers and designers without much assistance from usability experts. So the site might look great and have great content but still end up being hard to work with for the real users. Designers and developers are clearly power users of a Web site, but can the same be said for the intended audience of the site? A fundamental item in any usability checklist must be “Test the site on real users.”
Beyond that, you have the problem of ensuring that each page behave as expected and react as expected to users’ solicitations. This is another facet of testing—definitely a more developer-oriented facet.
To effectively test the site on real users and test the functionality of pages, tools are required. Tools to help test Web pages are a hot new field in the industry.
Testing the Logic of the Page
An ASP.NET Web Forms page results from the combined effect of a view template (ASPX) and a code-behind class. The code-behind class is responsible for any logic you want the page to expose. Testing a code-behind class is a matter of writing the code with testability in mind and then using a unit-testing tool such as the MSTest environment integrated in Microsoft Visual Studio 2010. (In Chapter 12, I’ll return to design principles and testability.)
The logic of the page is also responsible for the actual markup being sent to the browser. What is this markup? Is it relatively static? Or is it rich with JavaScript and dynamic behavior? If you consider the structure of the page trivial or just static, it might suffice that you ensure the correct data is assigned to server controls in the view template. This is not hard to figure out from a bunch of unit tests.
If the structure of the page might differ depending on run-time conditions or parameters, you probably need to look around for some tools that help you test the front end of a Web application.
Testing the Client-Side Behavior of the Page
Testing the front end of a Web application goes beyond classic unit testing and requires ad hoc tools. In this regard, ASP.NET Web Forms is not much different from ASP.NET MVC, or even from Java or PHP Web applications.
You need a tool that allows you to programmatically define a sequence of typical user actions and observe the resulting DOM tree. In other words, you want to test the layout and content of the response when the user performs a given series of actions.
Such tools have recording features, and they keep track of user actions as they are performed and store them as a reusable script to play back. Some tools also offer you the ability to edit test scripts or write them from scratch. Here’s a sample test program written for one of the most popular of these front-end test tools—WatiN. The program tests the sample page we discussed earlier with a drop-down list and a grid
public class SampleViewTests
{
private Process webServer;
[TestInitialize]
public void Setup()
{
webServer = new Process();
webServer.StartInfo.FileName = "WebDev.WebServer.exe";
string path