2008/4/5, Yoshihiro Tanaka <[EMAIL PROTECTED]>: > 2008/4/4, Micah Cowan <[EMAIL PROTECTED]>: > > > > > IMO, if it's worth testing, it's probably better to have external > > linkage anyway. > > > I got it. > > > > > > 1) Select functions which can be tested in unit test. > > > But How can I select them? is difficult. > > > Basically the less dependency the function has, more easy to > > > include in unit test, but about boundary line, I'm not sure. > > > > > > This is precisely the problem, and one reason I've been thinking that > > this might not make an ideal topic for a GSoC proposal, unless you want > > to include refactoring existing functions like gethttp and http_loop > > into more logically discreet sets of functions. Essentially, to get > > better coverage of the code that needs it the most, that code will need > > to be rewritten. I believe this can be an iterative process (find one > > function to factor out, write a unit test for it, make it work...). > > > Yes, since I want to write proposal for Unit testing, I can't skip this > problem. But considering GSoC program is only 2 month, I'd rather narrow > down the target - to gethttp funcion. > > Although I'm not well aware of source code, > I'm thinking like below: > > In gethttp function there are roughly six chunk of functionality. > > 1.preparation of request > > 2.making header part of HTTP > proxy_auth > generate_hosthead > , and other process to make header > > 3.connection > persistent_available_p > establishment of connection to host > ssl_connection process > > 4.http request process > request send > read request response > checking status codes > > 5.local file - related process ( a bunch of process...) > deterimine filename > file existence check > noclobber, -O check > timestamping check > Content-Length check > Keep-Alive response check > Authorize process > Set-cookie header > Content-Range check > filename dealing (HTML Extention) > 416 status code dealing > open local file > > 6.download body part & writing into local file > > > > So, Basically I think it could be divided into these functionality. > And after that each functionality would be divided into more > small pieces to the extent that unit tests can be done separately. > > In addition to above, we have to think about abstraction of > network API and file I/O API. > > But network API(such as fd_read_body, fd_read_hunk) exists in > retr.c, and socket is opened in connect.c file, it looks that > abstraction of network API would require major modification of > interfaces.
Or did you mean to write wget version of socket interface? i.e. to write our version of socket, connect,write,read,close,bind, listen,accept,,,? sorry I'm confused. > > And design of this would not be proper for me, I think. > So what I want to suggest is that I want to ask interface _design_. > How do you think ? At least I want to narrow down the scope within > I can take responsiblity. > > > > > What I'm most keenly interested in, is the ability to verify the logic > > of how follow/don't-follow is decided (that actually may not be too hard > > to write tests against now), how Wget handles various protocol-level > > situations, how it chooses the filename and deals with the local > > filesystem, etc. I will be very, _very_ happy when everything that's in > > http_loop and gethttp is verified by unit tests. > > > > But a lot of getting to where we can test that may mean abstracting out > > things like the Berkeley Sockets API and filesystem interactions, so > > that we can drop in "fake" replacements for testing. > > > > > I'd like to try, if we could settle down the problem of interface design... > > > > > I'm familiar with a framework called (simply) "Check", which might be > > worth considering. It forks a new process for each test, which isolates > > it from interfering with the other tests, and also provides a clean way > > to handle things like segmentation violations or aborts. However, it's > > intended for Unix, and probably doesn't compile on other systems. > > > > http://check.sourceforge.net/ > > > Thank you for your information :) > > > -- > > Yoshihiro TANAKA > -- Yoshihiro TANAKA
