From: "Tom Breton (Tehom)" <tehom@panix.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Proposal: Emtest as tester
Date: Mon, 24 May 2010 17:26:51 -0400 [thread overview]
Message-ID: <0bbc0d9ab1b84a87a1114077c5d72238.squirrel@mail.panix.com> (raw)
In-Reply-To: <5F014FD2-5988-406F-9683-ACF2E3096231@gmail.com>
At Carsten's request, I am proposing emtest as the tester for
org-mode. I would like to hear if there are any objections or
questions.
****** About Emtest
Emtest is an emacs-based test framework. It reads tests, runs them on
command and presents their results. Test suites can be run by suite,
by clause, or by library.
It is extensible and modular. Nearly everything about it can be
replaced or extended.
One important feature is its testhelp libraries:
* mocks/filebuf - for making mock files and buffers to run tests in.
* mocks/dirtree - for making mock directory trees.
* deep-type-checker - for testing that objects, especially
structures, are type-correct right down to their leaves.
* match - for pattern-matching. When you want to test return values
or similar, but some fields or elements don't have stable values
(say, a timestamp or a UUID).
* tagnames - extremely useful for defining test data and iterating
over examples.
* testpoint - useful for:
1. testing functionality that is called deep inside something else,
where writing a viable test would mean nearly cloning the
something else to get the calling conditions right.
2. Testing functionality that uses other functionality that can't
be easily controlled by passing arguments.
3. Testing that under given circumstances a certain point is
reached, not reached, or reached the right number of times.
Also, in less than perfect shape right now:
* mocks/keystuffer - work in progress, for capturing canned user input
* misc and standard - standard testhelp functions. Works but
undergoing reorganization.
* types - type specifications, extending what cl provides. Right
now, just a few that I needed.
* persist - useful for tests of inspected output. Not working right
now due to redesign of an underlying package.
****** Some questions
* Where to include it:
* I'm proposing to put it under org-mode/testing/ So the directory
structure would look like:
* org-mode
* lisp
* (etc)
* testing
* emtest
* Many files
* Some support
* packages emtest
* uses.
* org-agenda
* tests.el
* (And other test files)
* org-archive
* tests.el
* org-ascii
* etc (the other org files' directories of test files)
* (other existing org directories)
* Should testing of contrib files be in a separate directory? It's
not clear to me that it needs to be or should be.
* Loading.
Of course this shouldn't require much extra work to build and
install. Yet there's a case to be made for not building or
installing it by default, "them that don't use it doesn't pay a
cost".
So I'm thinking I should add another target to the makefile to
install it, as well as (of course) a test target.
* How to include it, git-wise.
What git wants to do with included external projects is to make
them submodules. However, I'm told that's a pain to deal with,
moreso from the other end than from mine. And it does seem like it
would be. Basically git treats a submodule as a single thing, but
still "signs" it version-wise with a hex ID, and wants it to be the
correct version. So git insulates you just a little bit, at the
cost of having to deal with an additional repository.
So I'm thinking I'd just include it literally and if that proves
hard to maintain then we still have the other option.
Tom Breton (Tehom)
next prev parent reply other threads:[~2010-05-24 21:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-29 22:24 org-html link building diff Tom Breton (Tehom)
2010-05-01 12:01 ` Carsten Dominik
2010-05-15 12:29 ` Carsten Dominik
2010-05-15 21:37 ` Tom Breton (Tehom)
2010-05-16 5:03 ` Carsten Dominik
2010-05-18 0:59 ` Tom Breton (Tehom)
2010-05-18 4:47 ` Carsten Dominik
2010-05-18 12:26 ` Sebastian Rose
2010-05-16 5:20 ` Carsten Dominik
2010-05-18 1:01 ` Test-file naming conventions - mine and suggested for org Tom Breton (Tehom)
2010-05-21 11:27 ` Carsten Dominik
2010-05-24 21:26 ` Tom Breton (Tehom) [this message]
2010-05-24 22:56 ` Proposal: Emtest as tester Dan Davison
2010-05-27 20:02 ` Tom Breton (Tehom)
2010-05-25 6:48 ` Carsten Dominik
2010-05-25 8:43 ` Martin Pohlack
2010-05-27 20:13 ` Tom Breton (Tehom)
2010-06-07 16:11 ` Benjamin Andresen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0bbc0d9ab1b84a87a1114077c5d72238.squirrel@mail.panix.com \
--to=tehom@panix.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.