[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#31336: closed (27.0.50; [RFC] Gnus mock testing se

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#31336: closed (27.0.50; [RFC] Gnus mock testing sessions)
Date: Tue, 09 Oct 2018 17:47:04 +0000

Your message dated Tue, 09 Oct 2018 10:46:29 -0700
with message-id <address@hidden>
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

31336: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31336
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 27.0.50; [RFC] Gnus mock testing sessions Date: Tue, 01 May 2018 14:56:11 -0700
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,

Attachment: gnus-mock.el
Description: Text document

Attachment: .gnus.el
Description: Text document

--- End Message ---
--- Begin Message --- Subject: [RFC] Gnus mock testing sessions Date: Tue, 09 Oct 2018 10:46:29 -0700 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
I'm just going to propose this as an Elpa package.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]