You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Necko test plans

Abstract:
Describes the contents and function of http://www.mozilla.org/quality/networking/testing/

Overview:
The directory future home of all Necko QA test cases.
The goal is to provide a set of functional test cases that would allow you to evaluate the standards compliance of any network browsing software.

Current tests
Name
 Comments
Network (general)
 Smoketest of major URL schemes, basic network connectivity and DNS tests
RFC URL scheme test
 Functional test of URLs specified in RFC 1680 and 1738. Coming soon
URL parsing test
 Functional test of URL syntax, including valid and invalid characters, escaping, etc. Coming soon
File URL functional test
 Functional test of file:// URL syntax. First release covers basic syntax, functionality and error handling. Re-write coming soon.
FTP URL functional test
 Functional test of ftp:// URL syntax. Coming soon, after FTP bug component review.
Proxy functional test
 Currently a draft smoketest
data: URLs
 RFC 2397 compliant test suite.

Results:
A table of results, by product.


General browser comments (which will eventually find a real home...)
From a networking perspective, the browser is actually a bundle of internet protocol clients, mostly using URLs as a common data structure, and hopefully with a friendly user interface. So this means that testing the browser has a structure to the problems that you want to test for.

Generic network tests - TCP/IP, UDP, and DNS behaviors are modular, and anyone that is using them would expect some basic connectivity, performance, and error issues. These unit tests would be applied to every protocol handler.

URL parsing - URLs are great, but they are also complicated. There is generic URL syntax, that every protocol handler should follow.

Specific protocols - each protocol has its own story. Each protocol may have specific URL syntax issues that need to be checked, as well as the actual testing of the protocol handler as a network client.
File: File URLs make the most sense when they are not used. File is built around a conflict between two concepts: having file URLs that look like other URLs, and providing a univeresal URL format that can map files from any local file system type. Additionally, a file URL tells people about a file on a local disk somewhere, which is often counter-intutitive at best, a security problem at worst.

FTP: FTP is all about diversity and legacy systems. FTP is one of the oldest protocols, and focused on giving interactive users a standardized command structure for finding and transfering files. As such, it did not strictly govern all data, especially data that is human readable (like dates). Much getting FTP to work is about creating connection logic that can work with a variety of servers and flexible response parsing.

Future tests:
FTP Functional test re-write
RFC 1738 based URL scheme and syntax test
RFC 1680 based URL scheme and syntax test