Re: [cpp-netlib-devel] localhost_tests failures

[Dean M. B. <mik...@gm...>]

On Wed, Sep 3, 2008 at 3:00 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Wed, Sep 3, 2008 at 08:44, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>>> I don't see how that's an improvement over saving test.xml with
>>> LF-only line endings, and get consistent test results...? I understood
>>> Divye's point to be that if we did that, we would mask something else.
>>>
>>
>> It's not about changing the test data to make sure the tests run, it's
>> more about making sure we get the correct data that we expect from the
>> HTTP Server -- and if I requested for a file that has CRLF line
>> endings in from the server, that I would get the exact same file if I
>> read it from disk in binary mode.
>
> The thing is, the server you're using cannot serve a file containing
> CRLF "for technical reasons" -- wouldn't it seem better to base the
> test off a file with LF only?
>
> That way you preserve the premise of the test, but change the details
> to compensate for the "technical reasons", so that the test is still
> valid.
>

We're not testing the serving of the file -- because that's Python's
domain, and we're not testing the Python server -- but rather we're
testing the reception of the file to make sure that *if* and *when*
the file contains CRLF line endings, that we catch it as is.

The premise of the test is:
- when we request a file that has CRLF line endings, we get it with
CRLF line endings
- cpp-netlib will not fail because having CRLF line endings in the
body should be acceptable
- CRLF line endings are preserved when the body of an http::response
is retrieved.

Of course, it assumes that the HTTP server will serve the file
correctly. In this case the problem is no longer the client, but the
server. In which case, since this failure only happens in Windows with
Python, and that it's a known bug in the server, then it's best that
we mark it as an expected failure due to a bug in the third party. If
there was anything that was going to be fixed, it is the Python
server, not the unit test or the test data. ;-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.