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. 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
