[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.

From: Darshit Shah
Subject: [Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.
Date: Thu, 30 May 2013 22:11:41 +0530

Hello to all!

As many of you may have noticed, I have been contributing to Wget over the
last couple of months. One of the major contributions has been support for
RESTful scripting. It is still not refined and a couple of bugs need to be
solved. That will be done before the window closes for the next release.

However, I am also a student and have applied to and been selected for the
Google Summer of Code, 2013. My proposal on which I am expected to work
over the next 2 months is titled: "Move Test bench Suite from Perl to
The complete proposal is public and can be viewed at:

Since this proposal affects the developers of Wget rather than the users,
and this mailing list reaches all the major contributors to GNU Wget, I
thought I should discuss the details on this list.

I have currently proposed a structure similar to the current one in Perl:
1. HTTPServer
2. HTTPTest
3. FTPServer
4. FTPTest
5. WgetTest
6. runTests

The individual test files will define the input URL’s and files, the
expected returned pages, files to exist on Server and expected return code
from Wget.
A runTests module will accept extra Command Line parameters for Wget and
will be used as the single point through which tests must be carried out.
The WgetTest module will accept the parameters from the test files which
may be overridden through parameters set through the runTests module. This
module will also be tasked with creating the various output files that are
required to be stored on the server. It will also fire up a HTTP / FTP
Server on a separate thread and execute the required Wget command and
collect it’s return code and output files.
The HTTPServer / FTPServer modules are to be tasked with simply creating
the respective servers with the required featureset (SSL, NTLM,
cookie-auth, etc.)

The main aim of this shift is to create a Test Environment that is more
robust and easier to extend in terms of new tests.

While this is what I proposed, I kindly request everyone to pitch in with
their suggestions on what they would like to see in the new test suite.
Features that are currently missing or nuances in the current test
environment. What should be there and what shouldn't?

Thanking You,
Darshit Shah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]