GNU bug report logs -
#31336
27.0.50; [RFC] Gnus mock testing sessions
Previous Next
Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Date: Tue, 1 May 2018 22:00:02 UTC
Severity: wishlist
Found in version 27.0.50
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Tue, 09 Oct 2018 10:46:29 -0700
with message-id <87efcz6miy.fsf <at> ericabrahamsen.net>
and subject line [RFC] Gnus mock testing sessions
has caused the debbugs.gnu.org bug report #31336,
regarding 27.0.50; [RFC] Gnus mock testing sessions
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
31336: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31336
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
Something I've wanted for a while is a fake Gnus session that I can use
for testing, since it's very hard to get Gnus up and running
meaningfully without substantial customization.
So I made the attached "gnus-mock.el" library. You start "emacs -Q", run
`gnus-mock', and get a repeatable trashable Gnus session you can use for
testing. What I did was put a basic Gnus installation under
./test/data/gnus/mock, and every time you start a mock session that
installation gets copied to a temporary directory, and Gnus operates out
of that directory for the duration of the session. You can abuse it
however you like, and then when you quit it gets cleaned up. It has some
hard-coded config (at present, just one nnmaildir server), and you have
the option of laying your own config over that.
It seems to work just fine. I can imagine all kinds of things we could
do with this, but I wanted to float this here before I went any further,
to get some feedback. Some things:
1. Ideally we'd have a bunch of messages in there, which can serve as
sort of regression tests, and may also be useful for unit tests as
well. Is there any concern about the size of data? My understanding
is that this data will be discarded in an actual install, so maybe it
doesn't matter so much?
2. I'm currently using `source-directory' to find the data dir. I guess,
if we're expecting this only to be used for development in the source
tree, then that's okay.
3. Locally, I wrote a python one-liner as a dummy `sendmail-program',
that just returns a 0 exit code. A python script isn't really
practical, and also I haven't done anything for the other mail
sending protocols. What I'd really like is a little executable that
accepts the message, and then sticks it in yet another directory
within the temp installation. Then we can point `mail-sources' to
that, and have a little boomerang where all sent messages come back
to you.
4. It's not possible to pre-configure directory-based servers in
`gnus-server-alist', as the directory paths need to be absolute, and
at present they change every time `gnus-mock' is started. Not a
tragedy, though.
I've attached the gnus-mock code, and the dummy .gnus.el config file --
later, once there's some feedback on this, I can push a branch that
contains the whole data dir.
Hope this is welcome,
Eric
[gnus-mock.el (text/plain, attachment)]
[.gnus.el (text/plain, attachment)]
[Message part 6 (message/rfc822, inline)]
I'm just going to propose this as an Elpa package.
This bug report was last modified 6 years and 228 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.