|Summary:||create a message parser test suite|
|Product:||Spamassassin||Reporter:||Justin Mason <jm>|
|Component:||Regression Tests||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Bug Depends on:|
Description Justin Mason 2005-08-26 09:44:56 UTC
Every now and again, we come up against bugs in our message parser (MIME, HTML, headers, base64/qp decoding, etc. etc.) We fix them, but occasionally there's regressions. Funnily enough, that's why regression test suites were invented! ;) So this bug is a reminder that we need to implement a regression test suite for our message parser, something like "t/messageparser.t". I envisage it as using a vast collection of message files, something like a mass-check corpus. I don't think it's necessary to distribute these message files, they could be in SVN only, in order not to bloat the distribution tarball with unnecessary tests.
Comment 1 Theo Van Dinter 2005-08-26 10:58:25 UTC
Subject: Re: New: create a message parser test suite On Fri, Aug 26, 2005 at 09:44:56AM -0700, email@example.com wrote: > So this bug is a reminder that we need to implement a regression test suite for > our message parser, something like "t/messageparser.t". > > I envisage it as using a vast collection of message files, something like a > mass-check corpus. I don't think it's necessary to distribute these message > files, they could be in SVN only, in order not to bloat the distribution tarball > with unnecessary tests. It's worth noting that we already have t/mimeparse.t to cover some of these, but not all obviously. I don't think there's really an issue distributing the messages, I actually think the rule can just generate them and throw through parse() to get the output. I've typically been doing some form of "parse this, then verify the correct internal part layout and sha1sum outputs", though there are likely other/better ways to do it.