[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] GSoC 2013 project on rewriting Test Suite in Python.
|
From: |
Tim Rühsen |
|
Subject: |
Re: [Bug-wget] GSoC 2013 project on rewriting Test Suite in Python. |
|
Date: |
Thu, 30 May 2013 21:53:11 +0200 |
|
User-agent: |
KMail/1.13.7 (Linux/3.8-2-amd64; KDE/4.8.4; x86_64; ; ) |
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\
<title>Main 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,
> Darshit Shah
>