On 29 Apr 2015, at 7:44, Dianne Skoll wrote:

On Wed, 29 Apr 2015 00:36:26 -0400
"Bill Cole" <mdlist-20140...@billmail.scconsult.com> wrote:

Built and installed 2.78 plus that patch, ~4 hours ago on my personal
system, works as intended without any sign of trouble on 219
messages, all single-rcpt.

Great!  It'll be in the next release.

Doing the build reminded me of a longstanding unreported bug in
t/unit/dates.t, in the rfc2822_date_works test.

I didn't write that test (we hired a summer student to improve the
MIMEDefang test suite... hah!) and have no idea why we're even *testing*
for date --rfc-822.  I'll revisit this at some point.

I am quite happy to hear that it was a summer intern who wrote that. It didn't seem up to the quality I'm used to seeing in MD and I'm glad it isn't a sign of encroaching senility (but I project...)

It seems to me that it's supposed to be a test of your rfc2822_date() subroutine, confirming (in the existing implementation) that it emits roughly the same thing as 'date --rfc822' while allowing for the two dte-time strings being generated in different seconds and even crossing minutes but not (oops) crossing hours. It seems like a quick few lines to allow a claim of testing every subroutine without subtle reasoning about what is being tested, how it might be broken in the real world, and how to definitively test for the likely types of breakage. My replacement is only slightly less ridiculous, in that it won't generate false failures for silly reasons but retains the ill-considered basic structure. A proper test might be longer than rfc2822_date() itself and ideally wouldn't involve trying to run the highly variable 'date' utility. I'd think a test of round-tripping rfc2822_date()'s output with POSIX conversion to a sane epoch time and back to the same string would be a real test of the code rather than the quirkiness of the 'make test' environment. However, I say that before my 3rd cup of coffee and without even the incentive of a summer intern's compensation...
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Reply via email to