The Network_selftest provides utility functions for the network module selftests, allowing batch URL loading and result comparisons, and User Interface simulation.
These utility functions were previously spread across the url, libssl and mime modules.
API documentation generated by Doxygen contains all necessary information for the external APIs.
Master class for managing batches (URL_DocSelfTest_Batch) of tests. This object owns all the batches added through AddBatch(). Testing of the batches, in the sequence added, starts when SetLastBatch() is called.
Selftest code must construct this object, then allocate and add batches and finally call SetLastBatch() in an async test.
Manages a group of testcases (URL_DocSelfTest_Item). This object owns all the testcases added through AddTestCase(). Loading is initiated by URL_DocSelfTest_Manager. All testcases in a batch are loaded in parallel.
Selftest code must allocate an object of this class, allocate and add testcases, before releasing it to the manager using Addbatch().
Base class for testitems. Based on URL_DocumentHandler. Should not be used directly as it only organizes the loading, does not perform any tests; those have to be implemented in subclasses. Loading is initiated by URL_DocSelfTest_Batch.
Selftest code must allocate and construct implementations of this class and add them to the batch using AddTestCase().
Simple testcase that loads a resource and compares it to a local file.
Tests a multipart/x-mixed-replace stream, comparing it to local files.
Load the specified text resource, then scan the content for the expected pass string.
Load a resource and check if it at least matches the specified security level.
Loads two resources, then compares them to check if they match at the binary level.
Loads a URL, passes if the loading succeeds.
This system is based on XML configuration files hosted on a remote server.
The manager of the tests. An async test uses an object of this class to add URLs for the specifications using the AddTestSuite() function.
Internally two classes RemoteFrameworkMaster and RemoteFrameworkTestSuites processes the XML files and constructs testcases using the above mentioned testclasses.
Fileformat is documented in framework-format.htmlThese can be used by an async testcase to wait for SSL autoupdates. Times out after one minute.
Implementations can create to override triggered dialog actions. This class connects the implementations to the testmanager. Default action is to use the pre-existing loading listener (which MUST be non-NULL) or the NullLoadingListener implementation.
Similar to BasicWindowListener, but for the SSL listener. This class connects the implementations to the testmanager. Default action is to use the pre-existing ssl listener (which MUST be non-NULL) or the NullSSLListener implementation.
Overrides the proxy preferences during a selftest.
API documentation generated by Doxygen contains information about the internal organization of the module.
The module is very small, and the code is only enabled for selftest builds, not production releases
All the functions handle OOM by returning a status to the caller. Such errors will usually result in the test reporting failure.
There is no particular OOM handling. A failure code is returned to the caller, which is expected to exit with a failure code of its own.
Part of the classes emulate UI listeners, and act based on callbacks.
Other classes are batch load managers that are configured by callers, then activated. After activation these classes are message driven and will perfrom various operations upon receipt of these messages.
Most data are stored in URLs, but the UI emulators may store a few strings. Processing steps can temprarily allocate buffers and other objects
Usually large objects are allocated on the heap. In some cases sizeable objects are placed on the stack but only for shorter periods. >
In most cases stack consumption should be less than 300 bytes.>
The module does not use any persistent storage. All longlived storage is managed by the caller, and freed by the caller, or by URLs.
All longlived data storage is maintained by the URL contained in some classes.
The code using these utilities are resposible for freeing all objects of these utilities they have allocated.
Some code uses a memory manager temporary buffer for some internal operations. These operations are fairly independent, and will not cause collisions with other users of the buffer.
At present there are no opportunities to tune memory use.
None. The classes are used directly and only by selftests. Selftests are not relevant as any test would have to duplicate testcases in other modules.
None. The classes are used directly and only by selftests. Coverage is not relevant.
The batch loaded classes are designed to perform various tests by loading URLs and comparing the result with some expected content, either by direct string comparison, or by comparing against a file.
The UI emulators are basic wrappers around the pre-exisiting listeners. Actual implementations will be based on these classes.
At present, no improvments are planned.