August 2008 - Posts

Testplan Checklist for Asp.Net
Tuesday, August 26, 2008 1:47 PM

a.k.a. The “I didn’t know I had to test that” checklist.

Each tester is responsible for ensuring that his/her feature integrates correctly with the rest of Asp.Net, which is a challenge because Asp.Net is a very big product and almost no one can keep all the different features in their head. To address this, our team maintains a "checklist" of integration points that each tester must investigate while creating his/her testplan. Each item links to a page with more information and resource links (which I omit here due to space), and the idea is for the tester to do research on each area and discuss with their feature crew if any interesting tests can be done with each point.

Federico Silva Armas
Asp.Net QA Team

 

Areas that are interesting to both controls and runtime features:
  • Output Caching(Page & User Control)
  • Trust levels
  • Async pages
  • Precompilation
  • NoCompile pages
  • Virtual Path Provider
  • Debugging
  • Languages: VB and C#
  • Impersonation
  • Perf counters
  • Browser dependencies
  • Custom errors
Areas that are interesting for controls:
  • Themes – is control themable?
  • UserControl – how does the control work inside the user control?
  • Master Pages – does control work inside a master page?
  • Viewstate on/off
  • Encryption of ViewState
  • Adaptive Rendering
  • Cross-page posting
  • Callbacks
  • Behaviour inside an Update panel
  • Behaviour inside MVC web site
  • Behaviour inside WebPart
  • XHTML conformance
  • Use Standard tests - automated test that verifies property values for controls
  • Tracing
Areas that are interesting for runtime:
  • Custom errors
  • Cassini Web Server
  • Domain Controllers
  • Http Intrinsics
  • Page lifecycle
  • Process identity
  • Process model, including differences b/w IIS7 classic and integrated mode
  • Time Zones
  • UNC
Areas that are interesting for script-based (Ajax) features:
  • Debug/release
  • Different browsers

Designer considerations

These scenarios are only interesting if your feature has a design-time (Visual Studio) component.

Environment
  • Code intellisense
  • JS intellisense
  • Config intellisense
  • Code behind
  • Solution item templates and project templates
Controls
  • Control is resizable
  • Source code preservation
  • Containers (both naming containers and not a naming container):i.e Table, Panel, Templates etc
  • Chrome
  • Right-click menu
  • HTML intellisense
  • Split view, Design view, HTML view switching
  • Cut/Copy/Paste
  • Drag/Drop
  • Undo/redo
  • Visible switch on the control
  • White space preservation
Dialogs and custom editors
  • Localized dialogs
  • Truncated text
  • Focus
  • Tab order
  • Default settings
  • Buttons to close, help, minimize
  • Accessibility

Global considerations

Here are some considerations you want to think about putting into your testplan.

Interesting areas to both controls and runtime features:
  • Globalization/Localization including “Turkish I”
  • Security
  • Side-by-side
  • Performance
  • 64-bit issues
  • OS-specific issues
  • Data: Sql versions (2000, Yukon, katmai etc). Flavors (developer edition, express, etc)
  • Data: Oracle, MySql, terradata, etc
  • IPV6
  • Error handling: are errors clear and actionable?
by farmas | 3 comment(s)
Filed under: ,
Master pages and their not so master life style
Friday, August 22, 2008 1:10 PM

There is no great secrete that I'm letting out of the bag but it is something that I never really had the need to stop and think about, it was just something that I took for granted.  Maybe I thought that it worked by some form of magic, maybe I just never cared, but today I'd like to talk about what a master page really is.  I always thought that a master page was simply that, a page.  This makes since based on the name and the behavior that it has right?, wrong.  If you open up reflector and take a look at the master page class it inherits from System.Web.UI.UserControl and not from page.  Once I stopped and thought about this for a minute it makes since. Master pages were introduced in FX 2.0 and by not adding anything as the parent of page there would be very little work that would need to be done to implement this. So how do we get the master page to appear to be the parent of page you might ask yourself.  Well here is were the ContentPlaceHolder and Content controls come into play.  They simply control where the page's content is placed when the page is rendered.  ASP.net is aware of the master page control, because of the reference in the page declaration, and places the markup inside the Content Control inside of the ContentPlaceHolder Control.  This gives the effect of the master page acting as the parent of page without actually changing the control hierarchy. Like I said this is no great secrete but simply something I had never stopped to think about.  The reason I stopped to think about it is that I plays a part in a feature I am working on for the next version of the framework, stay tuned for more information about that feature after PDC08.

by osbornm | with no comments
Browser difference when using "innerHTML"
Friday, August 15, 2008 2:07 PM

This week we found another subtle browser difference as we were running MVC Ajax tests. If you have been following the Asp.Net MVC project, you will know that we are currently working on adding an Ajax story to the framework. Basically, adding helper methods so that a developer can render links that do "partial view renderings" via XmlHttpRequests. For example:

         <%= Ajax.ActionLink("Ajax.ActionLink in View Insert Before", "ResultView",
            new AjaxOptions { 
                InsertionMode = InsertionMode.InsertBefore, 
                UpdateTargetId = "div1", 
            })%>

The result will be a link that when clicked will call the "ResultView" action on the controller, and append the response to the contents of a div with id="div1".

The test team uses an internal UI automation framework to write tests, and usually what we do is write the test for IE and then run it in all other supported browsers (Safari Mac, Safari Windows, Opera, FireFox Mac, FireFox Windows), and one of these tests ran into a difference between how innerHTML is handled between different browsers: In FireFox, innerHTML is the content of the element before whitespace normalization occurs; in IE, innerHTML is the content of the element after normalization.

The following page shows the difference:

<html>
<head>
</head>
<body>
<div id="foo">
    bar
</div>
<input type="button" onclick='alert("\"" + document.getElementById("foo").innerHTML + "\"");' value="What's in the Div?" />
<input type="button" onclick='document.getElementById("foo").innerHTML = "Here is some HTML inserted by javascript." + document.getElementById("foo").innerHTML;' 

value="Insert some HTML" />
</body>
</html>

 

When you click the first button, FireFox displays:

“
                bar
“

However, in IE it displays:

“bar “

Now, when you click the second button it simulates the MVC Ajax code that appends the content of the response to the div. And what you will get is, in FireFox:

“Here is some HTML inserted by javascript.
                This is div1
“

And in IE:

“Here is some HTML inserted by javascript.This is div1 “

It's a small difference in terms of visual rendering, but an extra space is shown on the browser. At the end, the MVC feature crew decided that consistency was better in this case and chose to fix our script code to handle this case. This is one case where having a good functional automation story can help to catch product issues.

Thanks to Andrew Nurse, the dev in MVC that investigated this problem.

Federico Silva Armas
Asp.NET QA Team

by farmas | 7 comment(s)
Filed under: ,
Tip on using Fiddler with cassini and localhost
Wednesday, August 13, 2008 11:03 AM

A lot of us use Fiddler to debug traffic from our applications. Fiddler doesn't work with requests to localhost. When debugging an ASP.NET website, we can always use the machine name instead of localhost. However, when using the ASP.NET development server (aka Cassini), we cannot use the machine name (since Cassini blocks requests other than localhost). We can hence do either of the following:

1. Append a "." to localhost.

So, if your url looks like: http://localhost:12825/, try using http://localhost.:12825/ instead. Or, if your url looks like "http://localhost/TestApp/Test/Default.aspx", try using
http://localhost./TestApp/Test/Default.aspx" instead. It works with fiddler    


2. Within Fiddler, on the menu, click Rules->Customize Rules. Within the function OnBeforeRequest(oSession:Fiddler.Session), add the following:

if(oSession.host == "<machinename>:<port>")
{
 oSession.host="localhost:<port>";
}

 If this doesn't work, just change the line to be oSession.host="127.0.0.1:<port>";.

and now make a request to http://machinename:<port>. This way fiddler gets the request and cassini gets it too.

Have fun using fiddler. Here it is (http://www.fiddlertool.com/fiddler/).

Introducing the Team
Friday, August 01, 2008 8:26 PM

I thought that the first post should lay some common ground about how the team is composed and what products we ship.


Internally, the ASP.NET Team has been renamed a couple of times (things like, "Web Platform and Tools", "UIFx Server") but no matter the name, our team is responsible for delivering what is commonly known simply as "ASP.NET ". Some of the things that ship directly from our team:

 

  • The big pieces
    • Everything in the System.Web assembly that is shipped as part of the .NET framework.
    • Everything in System.Web.Extensions assembly (what was formerly known as the Atlas project).
  • Other less known pieces
    • We own the control designers for all the controls that we ship as part of the framework, these are included in the System.Design assembly.
    • The MMC snap in to configure an ASP.NET site.
    • All the aspnet_*.exe that you see in the framework directory (like aspnet_regiis.exe, asonet_regsql.exe).

 

The ASP.NET team is subdivided into 3 main disciplines: PM Team, Dev Team and the QA Team (which is pretty common within Microsoft). Needless to say, we all work very closely together, but each team is specialized in its own discipline.

 

Now, talking about the QA team. We are a team of 15 testers, and our goal is quite simple: ensure that the right set of features for our customers are delivered with the right level of quality. In a day to day basis, the main responsibilities of a tester in our team are:

  • Contribute in the design of features along side Dev and PM. This is an area that makes ASP.NET a great team for testers to work in: we can directly contribute to the design of the product.
  • Act as the customer and build web applications to validate the design and implementation of the product.
  • Ensure quality of the product in the following areas: functionality, stress, performance, security, accessibility, localization, globalization, hosting, etc.
  • Write automated tests to ensure code changes do not regress existing functionality.
  • Being the last gate keepers of every release, we are responsible for making the final sign off for a product to be shipped.
  • Acting as developers, we design and implement our test infrastructure, framework and tools.
  • Service all previous versions of ASP.NET, ensuring the right quality of hot fixes and patches by running our automated test bed.

 

In future posts we plan to present several of our test methodologies, share our experience on what has worked well, how we write and run automated tests and tips on how test ASP.NET

 

And since I have been asked several times before: for those interested, there are 7 program managers in the PM team and 21 developers in the Dev Team. If there is interest, we can describe the tasks that each discipline has within the team in some later post.

 

Federico Silva Armas

ASP.NET QA Team

 

Asp.Net QA Team

by farmas | with no comments
Filed under: ,
More Posts