[squeak-dev] Network tests coverage (Re: WebClient-Core port to Pharo 1.1 final)

Andreas Raab andreas.raab at gmx.de
Thu Sep 2 03:30:59 UTC 2010


Hi Sven -

Good question. It would definitely be good to cover those areas with 
tests but I fear that may require actual cooperation :-) If there is 
enough energy (which is hard to say) one might be able to start a 
"neutral" repository with tests but I'm not sure how well it would work 
in practice (it would mean the tests are fairly far away from the source 
it's covering which is generally not a good thing). If anyone has good 
ideas, please propose.

Cheers,
   - Andreas

On 9/1/2010 12:38 PM, Sven Van Caekenberghe wrote:
> Andreas,
>
> Thanks a lot for taking the time to look into these problems and for the patches.
> Shouldn't we try to capture these problems with unit tests running across Squeak and its derivatives ?
> What would be the procedure to contribute to these tests ?
>
> Sven
>
> On 01 Sep 2010, at 06:16, Andreas Raab wrote:
>
>> Hi Sven -
>>
>> I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue.
>>
>> The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header.
>>
>> Fixes attached. These are of course also broken in Pharo 1.0 and 1.1.
>>
>> Cheers,
>>   - Andreas
>>



More information about the Squeak-dev mailing list