Re: [Bug-wget] [GSOC 2017] Design and implementation of a statistics module

[Tim Ruehsen]

On Tuesday, March 21, 2017 10:47:23 AM CET Avinash Sonawane wrote:
> On Mon, Mar 20, 2017 at 9:39 PM, Darshit Shah <address@hidden> wrote:
> > As for some low hanging fruits, have you tried looking into the bug
> > tracker? DO you see something interesting?
> 
> Yes. Currently I'm working on https://github.com/rockdaboot/wget2/issues/143
> > Apart from that, try using Wget2 as much as possible. Try to find cases,
> > where it breaks compatibility with Wget 1.x, or corner cases that break
> > expectations / cause wget2 to crash. File issues about those and see if
> > you
> > would like to solve those issues.
> 
> Ok. Good idea. Thank you!
> 
> > Another simple low hanging fruit is to improve the test coverage of
> > libwget
> > and wget2. Try to write new unit tests and integration tests to ensure
> > that
> > regressions are not introduced in the future.
> 
> Haven't written unit tests before. Let me read more up on how to write
> unit tests in C. I don't think it'll be that difficult though.

Just as a hint:

tests/test.c contains test routines that calls the libwget API directly (far 
from being complete).

The other tests/*.c contain tests calling the wget2 executable. Often we have 
several tests within one C file, using the same or very similar server settings 
and server files.

Let's take tests/test-robots.txt as an example...
- You have a normal main() routine
- In main() you start the server with wget_test_start_server(), giving it the 
array of files that should be present for the server (wget_test_url_t urls[]).
The server is started as a thread in the background.
- Now you start one or more tests by calling one or more times wget_test().
Here you specify the options for wget2, the requested URL, the expected status 
code from wget2, and the expected downloaded files. There are more options, 
you'll encounter them in other tests.
- Whenever an error occurs (expected status code is different or the expected 
downloaded files doesn't match, wget_test() won't return and just calls 
exit(EXIT_FAILURE).

To create a new test, either add it to an existing C file (if it is just a 
variation of some existing test) or create a new C test file (Add it to 
Makefile.am as well).

Whenever you change a Makefile.am, cd to the project dir and execute ./
config.status or execute ./autoreconf && ./configure.

After a 'make check', everything in tests/ will be built.
To debug a single test (e.g. test-new.c), you can cd to tests/, and execute it 
directly with ./test-new. The output is printed to the screen. Or execute it 
via 'make check TESTS=test-new', the output is now in test-new.log.

You can also valgrind your test with 'valgrind ./test-new' or 
'TESTS_ENVIRONMENT="VALGRIND_TESTS=1" make check TESTS=test-new'.

Or maybe easier from the project directory: 'make check-valgrind TESTS=test-
new'.

Regards, Tim

signature.asc
Description: This is a digitally signed message part.