Subject: bug#31336: closed ([RFC] Gnus mock testing sessions)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 09 Oct 2018 17:47:05 +0000

Your bug report

#31336: 27.0.50; [RFC] Gnus mock testing sessions

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
31336: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31336
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: [RFC] Gnus mock testing sessions
From: Eric Abrahamsen <[email-masked]>
To: [email-masked]
Date: Tue, 09 Oct 2018 10:46:29 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: 27.0.50; [RFC] Gnus mock testing sessions
From: Eric Abrahamsen <[email-masked]>
To: [email-masked]
Date: Tue, 01 May 2018 14:56:11 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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