QA/Firefox3.5/ViewSource Testplan: Difference between revisions

m
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
<small>[[QA/Firefox3.1/TestPlan|&laquo; QA/Firefox3.1/TestPlan]]</small>
<small>[[QA/Firefox3.1/TestPlan|&laquo; QA/Firefox3.1/TestPlan]]</small>


;Feature <abc> Test Plan
;Feature View Source Test Plan


= Overview =
= Overview =
Line 57: Line 57:


There should be an emphasis on view-source fidelity because it is very amenable to automated testing, and because it's extremely important.
There should be an emphasis on view-source fidelity because it is very amenable to automated testing, and because it's extremely important.
==== Is the page source being retrieved from the cache? ====
View Source is designed to retrieve the source for a page from the browser cache whenever possible.  This is because a server may return different data on two different requests, perhaps substantially so.  Generally, when the user chooses to view the source of a particular page, they want to see the original source used to render the page they're looking at, not whatever source the server returns from another request.
The easiest way to test this logic is with an HTML form that posts back to its own URL.  If the original form page and the page returned by the post look very different, then it's easy to test.  Submit the form, wait for the response, and then view source to verify that view source shows the HTML for the response, not the original form.  See bug [http://bugzilla.mozilla.org/show_bug.cgi?id=469302 Bug 469302].


== Linkification of HREF and SRC URLs in Firefox 3.1 ==
== Linkification of HREF and SRC URLs in Firefox 3.1 ==
Line 62: Line 68:
A two pronged approach will be used for testing the linkification feature: Automated testing (using Mochitests) wherever possible, and manual testing elsewhere.  Since view source is heavily used by web developers and linkification has been a much requested extension, we can reasonably expect good test coverage from beta users.
A two pronged approach will be used for testing the linkification feature: Automated testing (using Mochitests) wherever possible, and manual testing elsewhere.  Since view source is heavily used by web developers and linkification has been a much requested extension, we can reasonably expect good test coverage from beta users.


# Does linkification work at all? Mochitest can load a view-source page into an IFRAME and then scan the DOM for anchor elements.  Anchor elements will only be present if linkification is in effect.
==== Mochitests ====
# Are links being built correctly?  A Mochitest can examine the HREF attributes on anchor elements inside the view source page and can verify they are being built correctly.
 
# Do back and forward work? It might be possible to test this using the IFRAME approach and triggering back and forward programmaticallyThis won't test key bindings, but key bindings are simple to test manually.
The basic linkification functionality should be amenable to automated testing with Mochitests. The proposed approach is to embed view-source pages into Mochitest pages using IFRAME elements.  Once a view-source URL has loaded into an IFRAME, the test code in the Mochitest page can examine its DOM looking for anchor elements -- currently the only way an anchor element can end up in the DOM of a view-source page is through the linkification feature.
# Do back and forward key bindings work?  This really needs to be tested manually.
 
By using a carefully crafted HTML page as the target of the view-source URL in the IFRAME it should be possible to test most of the basic aspects of linkification, starting with "Does linkification work at all", and moving to some of the thornier cases like entity expansionMost of the test cases described in the section '''URL types''' below should be amenable to this sort of testing.


==== Manual Testing ====


# Entity expansion is not carried out when view-source URLs are built (it should be).
Some aspects of the linkification feature will most likely need to be tested manually, at least in the near termIn particular history navigation -- i.e. <Back> and <Forward> will be easier to test manuallySee the table in the ''Navigation through history'' section below.
# URLs that point to non-text resources (most especially images) are still turned into view-source URLs which will try to interpret them as text.  Since we don't need the mimetype to know for sure what sort of resource is being referenced, a smarter view-source handler is neededA view-source URL pointing to an image should be rendered as a regular URL pointing to an image would beThis might be difficult to test programmatically, but it's pretty easy to test manually.


==== URL types ====
==== URL types ====
Line 227: Line 234:
=== Bugs that describe how View Source works (or is supposed to work) now ===
=== Bugs that describe how View Source works (or is supposed to work) now ===


* [http://bugzilla.mozilla.org/show_bug.cgi?id=469302 Bug 469302]: Page source code after form submit shows initial form page instead of new page
* [http://bugzilla.mozilla.org/show_bug.cgi?id=15364 Bug 15364]: Add line numbers to View Source
* [http://bugzilla.mozilla.org/show_bug.cgi?id=15364 Bug 15364]: Add line numbers to View Source
* [http://bugzilla.mozilla.org/show_bug.cgi?id=17612 Bug 17612]: view-source link-browsing
* [http://bugzilla.mozilla.org/show_bug.cgi?id=17612 Bug 17612]: view-source link-browsing
1,457

edits