Thursday, January 6, 2011


I was not sure if I would be using these since I am testing a web application. CodedUI Tests can do things that the Web Performance Tests can't do like validating error messages generated through JavaScript. I used the CodedUI Test to validate an error message when username or password is empty; the error message is generated by JavaScript. The web tests cannot verify that error message since the page didn't so a post back.

Web Performance Test - Expected HTTP Status Code

I have a web performance test that is submitting an invalid username and password and verifying the error message is "Invalid Username or Password". I added a data source from csv file and started putting a bunch of different values in it. When I ran the data driven test some of the rows failed because page validation is enabled and the .NET Framework throws an exception. This happened if the username or password contained script tags.

Since some of the requests failed, I made another web test for the failures; browse to the login page, enter script tags in the username and password, and click the Login button. The test was failing because it returned a 500. There is a way to validate the HTTP status code returned by a Web Performance Test request. There is a property on the request called Expected HTTP Status Code. When it is 0 a return code in the 200 – 300 range is success. I set the Expected HTTP Status Code to 500 to verify error page is returned when script tags are input to username/password and also checked for this text: "System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (userNameTextBox="")."

I ended up with two data driven tests for the login page. One to check for the normal error message when login information is incorrect and another to check that page validation is working when script tags are submitted.

This is the error page when request validation is enabled:

Server Error in '/WebPARCS' Application.

A potentially dangerous Request.Form value was detected from the client (userNameTextBox="").

Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.

Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (userNameTextBox="").

Source Error:

[No relevant source lines]

Source File: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\webparcs\b39bbbab\1a2d57ab\App_Web_gjejbkkx.0.cs    Line: 0


Tuesday, January 4, 2011

VS2010 Schema Compare only works when databases are on the local drive

In Visual Studio 2010 Ultimate there is an option called Data> Schema Compare. I was unable to compare two databases on the test server. Visual Studio generated an error message of "Schema information could not be retrieved because of the following error: InternalError: SqlCeManager could not be initialized."

I found this post with the answer: "The error message is not accurate as what the specific issue is, its actually hitting an unsupported case.  SQLCE can not work against remote storage or mapped drives. It has to use a local drive for its sdf files and cache."

So I am unable to use Schema Compare because these databases are too big to copy and restore locally. Seems like a pretty big limitation to me.