More tests

[openstrike]

Here are some more tests to push up the coverage.

While adding these I noticed that the checks for encodings in HTTP::Message were not consistent (eg. decode checked for "identity" or "none" but encode only for "identity"). This seemed to be an oversight so I have added in the aliases. This is the only change made to anything other than the test suite.

This work has been done as part of the CPAN PR Challenge. Thanks for taking part.

[oalders]

@openstrike thanks very much for this! It looks like the builds are failing for anything less than Perl 5.18

[openstrike]

Apparently so. Oddly, I've been testing on 5.16.3 without issue. I will see about applying a patch for the older versions.

[openstrike]

The patch seems to have done the job. Note that all this does is skip the 2 problematic tests on those perls where they were failing. You might or might not consider the relevant code within the module to be a problem (line 173 of HTTP::Config which attempts to call can() on the argument to matching())

[skaji]

Current master:

❯ prove -l t
t/common-req.t .............. ok
t/headers-auth.t ............ ok
t/headers-etag.t ............ ok
t/headers-util.t ............ ok
t/headers.t ................. ok
t/http-config.t ............. ok
t/message-charset.t ......... ok
t/message-decode-xml.t ...... ok
t/message-old.t ............. ok
t/message-parts.t ........... ok
t/message.t ................. ok
t/request.t ................. ok
t/request_type_with_data.t .. ok
t/response.t ................ ok
t/status-old.t .............. ok
t/status.t .................. ok
All tests successful.
Files=16, Tests=577,  1 wallclock secs ( 0.10 usr  0.04 sys +  1.00 cusr  0.13 csys =  1.27 CPU)
Result: PASS

This PR:

❯ prove -l t
t/common-req.t .............. ok
t/headers-auth.t ............ ok
t/headers-etag.t ............ ok
t/headers-util.t ............ ok
t/headers.t ................. ok
t/http-config.t ............. ok
t/message-charset.t ......... ok
t/message-decode-xml.t ...... ok
t/message-old.t ............. ok
t/message-parts.t ........... ok
t/message.t ................. 1/191 Useless content call in void context at t/message.t line 574.
t/message.t ................. ok
t/request.t ................. 1/26 Use of uninitialized value $str in substitution (s///) at /Users/skaji/src/github.com/libwww-perl/HTTP-Message/lib/HTTP/Request.pm line 22.
Use of uninitialized value $request_line in split at /Users/skaji/src/github.com/libwww-perl/HTTP-Message/lib/HTTP/Request.pm line 31.
t/request.t ................. ok
t/request_type_with_data.t .. ok
t/response.t ................ 1/64 Use of uninitialized value $str in substitution (s///) at /Users/skaji/src/github.com/libwww-perl/HTTP-Message/lib/HTTP/Response.pm line 25.
Use of uninitialized value $status_line in pattern match (m//) at /Users/skaji/src/github.com/libwww-perl/HTTP-Message/lib/HTTP/Response.pm line 35.
Use of uninitialized value $status_line in split at /Users/skaji/src/github.com/libwww-perl/HTTP-Message/lib/HTTP/Response.pm line 39.
t/response.t ................ ok
t/status-old.t .............. ok
t/status.t .................. ok
All tests successful.
Files=16, Tests=739,  1 wallclock secs ( 0.10 usr  0.04 sys +  1.01 cusr  0.14 csys =  1.29 CPU)
Result: PASS

@openstrike Could you silence tests?

[openstrike]

Commit a7c6ba1 silences the carp from t/message.t.
The other warnings were inherent in the module code so it seemed more sensible to fix them there.
The test suite now runs silently for me - let me know if you still see warnings.

[skaji]

• I don't think HTTP::Request/HTTP::Response's parse method expects undef as an argument. So I would leave warning messages as they are.
• So instead of a7c6ba1, how about this? https://gist.github.com/skaji/19e1093b265d67e3327be9824d145567
• By the way, by $m->content in void context, what do you want to test?

I would like to hear thoughts of other maintainers.

[oalders]

@skaji's diff (and thoughts in general) look good to me.

[openstrike]

If the consensus is that the modules should issue warnings when called with unexpected arguments (such as undef) then should not the warnings issued be (a) clearer to the user and (b) refer to the offending line in the calling code? ie. should they not be using carp() just as the error message about void context does?

If so, the test suite should then be extended to check that such warnings are correctly generated.

[openstrike]

There's a new branch at coverage-test which includes commit 8f94464 implementing my suggestion about carp above. If you are happy with this approach let me know and I'll merge it into this PR. Thanks.

[oalders]

@skaji thoughts on the comment above?

[skaji]

I have no objection to the commit 8f94464.

BTW, I don't think we need to check $^W, because we usually don't execute perl with -w nowadays;
Once we decide on using carp(), call carp() always.
Sorry, I missed your comment.

should they not be using carp() just as the error message about void context does?

HTTP-Message/lib/HTTP/Message.pm

Line 135 in b9f1c04

Carp::carp("Useless content call in void context") if $^W;

[oalders]

We've also got a merge conflict here.

[openstrike]

Thanks for the feedback. I've merged the changes from coverage-test into coverage (this PR) and have (hopefully) resolved the merge conflict.

Travis is reporting failures in response.t now. I will check those and get back to you.

[oalders]

@openstrike thanks for this. It looks like we have a failing build now.

[openstrike]

All tests pass and there are no merge conficts as of now.

[oalders]

Thanks for this! Closed via 74b9567