emacs-orgmode
[Top][All Lists]
Advanced

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

[Orgmode] Re: Proposal: Emtest as tester


From: Dan Davison
Subject: [Orgmode] Re: Proposal: Emtest as tester
Date: Mon, 24 May 2010 18:56:52 -0400
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

"Tom Breton (Tehom)" <address@hidden> writes:

> 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.

Hi Tom,

My googling didn't manage to find emtest -- where does the code live at
the moment? Is there an Org repo out there demonstrating how it would
integrate, and/or some documentation and examples of usage?

Dan

>
> ****** 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)
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode



reply via email to

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