GNU bug report logs - #31336
27.0.50; [RFC] Gnus mock testing sessions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31336 in the body.
You can then email your comments to 31336 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; [RFC] Gnus mock testing sessions
Date: Tue, 01 May 2018 14:56:11 -0700

[Message part 1 (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 #8 received at 31336 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: 31336 <at> debbugs.gnu.org
Subject: [RFC] Gnus mock testing sessions
Date: Wed, 09 May 2018 11:29:56 -0700

Hmm, given the crickets here, maybe this would be better off as an ELPA
package?

Message #13 received at 31336-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: 31336-done <at> debbugs.gnu.org
Subject: [RFC] Gnus mock testing sessions
Date: Tue, 09 Oct 2018 10:46:29 -0700

I'm just going to propose this as an Elpa package.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.