Re: [Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.
Hi all, It's been nearly 2 months since the last mail and the time for Google Summer of Code is over. I have just pushed the last commit before the Window for the GSoC project code closes. I want to give an overview of the current state of the Test Suite and gain some more feedback on it. As multiple people suggested, I should have used a script based approach as XML wasn't very readable in the long run. I realized that quickly when trying to read the files without my Syntax Highlighting rules. So, I took some time off to completely revamp that part of the code and now tests are written as python scripts. The syntax is very similar to the the old perl based scripts, with subtle and important differences. Apart from that, I have also tried to make the code much lighter by using a threads to spawn a server instance, instead of the bulky multiprocessing code earlier. The test environment is currently in a usable state, but provides very few features. Support for IRI, SSL and REST commands needs to be added. However, that is not very difficult and one can easily edit the HTTPServer.py module to add the required features. I have tried to ensure that the code is well documented so it should be easy to work on it. Support for the FTP tests is a little more tricky and I will continue to work on it and finish it. One major advantage that this Test Suite brings over the older Perl Suite is the support for testing the parallel-wget branch, which is quite broken and requires a lot of refactoring work. As a result, I've been spending a considerable amount of time in adding this support and identifying ways to find bugs and issues in that code. The current working code can be found on my GitHub profile[0]. The old testenv-working and release branches are now obsolete. I have realized the errors of my ways and learnt to use git in a better fashion now. Please do go through the code base and let me know if there are any changes required. Any help in adding more features to this test suite is also appreciated! Our aim is to completely replace the Perl based tests. and I am close to accomplishing that for HTTP requests for now. [0] https://github.com/darnir/wget-gsoc/tree/Working -- Thanking You, Darshit Shah
Re: [Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.
Am Samstag, 29. Juni 2013 schrieb Tim Rühsen: Python 3.3 is no yet available in Debian unstable nor in experimental. Arg, I have to correct myself. I installed Python3.3.2 this morning from the Debian repository. I just edited the minimum required version to 3.2. However, if 3.3.2 is available in Debian unstable. it is very good, since there is a certain feature only available since v3.3 which I would like to make use of soon. -- Thanking You, Darshit Shah
Re: [Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.
Hello, sorry to randomly but in. Hello. Always glad for more inputs. On Sat, Jun 29, 2013 at 9:59 PM, Darshit Shah dar...@gmail.com wrote: An option would be to support XML (e.g. Test-xyz.xml) and a simple key/value text file (e.g. Test-xyz.txt). Both, XML and TXT have their pros and cons. So I won't say, one is better than the other... but it gives contributors a choice. Not a bad idea. Though I would be wary of having two different formats in which tests are written. Fragmentation isn't always a good choice. I would prefer to stick to one option. If there are others who too would prefer a TXT config file, I will switch to that. Is there any reason why the test definitions couldn't be written in plain Python? Giuseppe too was of the opinion that I should create the tests in Python itself. However, my reasons for not depending on any language were that language-agnostic tests can be re-used if the driver script is changed to another language in the future. The TXT format Tim suggested is prety much valid Python syntax already. You might need to an import at the top, like from defaults import *. Yes, I think by simply importing these tests, we could set the relevant variables and use them to configure the server. But that also implies using unsanitized input in our scripts. We should maybe run a sanity check on them before imports. But handleable. I think more people are for Text Based files, so maybe I'll shift it in that direction. Will require some more time since I should also start working on implementing a few other features. (Cookie, authentication support, etc) -- Thanking You, Darshit Shah
[Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.
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 Python. The complete proposal is public and can be viewed at: https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/darnir/1 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
Re: [Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.
Hi Darshit,
congratulations for your selection !
I didn't know about your proposal, so I couldn't post my opinion...
In your proposal you write:
The suggestion as one dev put it, “I would prefer a C test environment for a
C project, having tests written in C”.
I guess that was me ;-)
This is however, not an optimal solution. A major issue with writing the test
environment in C is the execution of external binaries. This would create a
lot of code clutter which can be easily avoided through the use of a
scripting language.
I can't see this. The only external program that has to be executed (for every
test) is Wget. Tests can always be merged into one executable, if that is a
point anyway.
I know it is too late now (typical non-communication fault), but must have
said that: I already started rewriting the test suite to C. (It is more a
spin-off of writing a libwget - with that it was easy to implement a HTTP/HTTPS
server).
I still appreciate your work - Python is way closer to C than Perl is.
So, if you have questions regarding the test suite or need some help, don't
dare to ask me. I guess a Python test suite will look very similar.
Just a snippet from a C(99) Test program (I still use mget/MGET prefixes, think
of MGET as WGET):
#include libtest.h
static const char *mainpage = \
html\n\
head\n\
titleMain Page/title\n\
/head\n\
body\n\
p\n\
Some text and a link to a a href=\http://localhost:
{{port}}/secondpage.html\second page/a.\n\
Also, a a href=\http://localhost:{{port}}/nonexistent\;broken link/a.
\n\
/p\n\
/body\n\
/html\n;
int main(void)
{
mget_test_url_t urls[]={
{ .name = /index.html,
.code = 200 Dontcare,
.body = mainpage,
.headers = {
Content-Type: text/html,
}
},
};
// starting the server thread in the background
mget_test_start_http_server(
MGET_TEST_RESPONSE_URLS, urls, countof(urls),
0);
// 1. test--spider
mget_test(
MGET_TEST_OPTIONS, --spider,
MGET_TEST_REQUEST_URL, index.html,
MGET_TEST_EXPECTED_ERROR_CODE, 0,
0);
// 2. test--spider-fail
mget_test(
MGET_TEST_OPTIONS, --spider,
MGET_TEST_REQUEST_URL, nonexistent,
MGET_TEST_EXPECTED_ERROR_CODE, 8,
0);
// ... implemented ~30 test cases yet
}
Regards, Tim
Am Donnerstag, 30. Mai 2013 schrieb Darshit Shah:
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
Python.
The complete proposal is public and can be viewed at:
https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/darnir/1
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,
