From: Sebastian Rose <sebastian_rose@gmx.de>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Emacs-orgmode mailing list <emacs-orgmode@gnu.org>,
Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: Re: Testing --- again...
Date: Mon, 04 Oct 2010 05:59:26 +0200 [thread overview]
Message-ID: <87tyl2vc9t.fsf@gmx.de> (raw)
In-Reply-To: <87vd5ibve8.fsf@gmail.com> (Eric Schulte's message of "Sun, 03 Oct 2010 19:26:39 -0600")
"Eric Schulte" <schulte.eric@gmail.com> writes:
> Hi,
>
> I've taken the liberty of merging our two testing branches into the new
> "combined-testing" branch. This now includes both ert and jump.el as
> git submodules, which can be installed with
>
> git submodule init
> git submodule update
>
> after checking out the branch. In merging the two org-test.el files, I
> was able to remove much of the existing code through using which-func,
> jump.el. The new navigation functionality will work regardless of the
> directory structure, so tests for file
>
> lisp/org-foo.el
>
> can be located in either of the following
>
> testing/lisp/test-org-foo.el
> testing/lisp/org-foo.el/test.el
>
> Additionally the navigation functions defined in jump.el should be
> easily extensible to accommodate new naming schemas, so ideally every
> test author for a particular file can use whatever naming system they
> prefer. Note that the navigation function `org-test-jump' when called
> with a prefix argument uses your code from
> `org-test-edit-buffer-file-tests' to create the test file if it is not
> already present.
>
> I think I retained most of the functionality from your version of
> org-test.el in the merge but please let me know if I broke something.
> In my mind this merged version should be small clean and maintainable
> and hopefully flexible enough to handle whatever needs we identify
> during the course of writing the tests. How would you feel about using
> this as the new base of test development?
>
> Best -- Eric
>
> also I have some inline comments below
Hi Eric,
that's good news!
> Sebastian Rose <sebastian_rose@gmx.de> writes:
>> What does which-func.el that this function does not:
>>
>> <#part type="application/emacs-lisp" disposition=inline>
>> (defun org-test-which-func ()
>> "Return the name of the current defun."
>> (save-excursion
>> (save-match-data
>> (end-of-line)
>> (beginning-of-defun)
>> (if (looking-at "(defun[[:space:]]+\\([^([:space:]]*\\)[[:space:]]*(")
>> (match-string-no-properties 1)
>> (error "No defun found around point.")))))
>> <#/part>
>>
>> ??
>>
>
> I'm not sure that it does include anything new, but it's nice to re-use
> existing packages.
And a dependency.
>
>> * Keymap
>>
>> We should add keys to the org-mode-map.
>>
>> C-c t
>>
>> is still free here. Or is it in you use it for babel somehow?
>>
>> C-c t f org-test-test-current-function
>> C-c t b org-test-test-current-buffer-file
>>
>>
>
> Wouldn't we want the keys in the elisp-mode key map, since we'll be
> doing the testing work from elisp?
Errrmmm, yes, we definetively want the keys in the emacs-lisp key map :)
> Although I guess we may want to run
> tests from within Org-mode files, but then we could do that with a Babel
> block and dump the results to a table. :)
Ho ho ho ho ho!
>> * ERT Selectors
>>
>> I see a little namespace problem coming up. Imagine testing org.el.
>> Which ert selector would we use?
>>
>> "^org" ??? :-/
>>
>> Should we create hashes of filenames as selectors (just kidding)?
>> Or use the entire filename "^org.el"? The relative path
>> "^lisp/org.el"?
>>
>
> oh, good point, maybe we'd need to use the "eql" or "tag" ert selectors
> in this case.
It's a flaw in Org's namespace actually. A defun's name in org.el could
clash with the name of a defun in another file in org-mode/lisp/.
The defun `org-imenu-get-tree' in org.el could clash with a defun with
that very name in a new file "org-imenu.el".
I guess we'll have to handle org.el in a special way.
>> If you checkout ert-testing, eval testing/org-test.el and do
>>
>> M-x org-test-edit-buffer-file-tests
>>
>
> In the combined-testing branch you'd do this by calling org-test-jump
> with a prefix argument.
Perfect.
>> Every one who saw that directory structure simply asked "don't you
>> think it's overkill?" :D I'll probably drop that.
>>
>
> heh, yea I'd lean towards getting into the writing of tests and then
> leaving our implementation flexible enough so that we can adopt this
> more fine-grained directory structure when/if it becomes necessary.
Eric, so just let's skip the directory structure. We could always
enforce something like that once we feel it's necessary.
We just want some reliable way to load the sensible tests (for a defun,
file, module or whatever) and execute them with just a key stroke.
Adding new tests for an existing elisp file should be just as easy.
As jump.el and which-func.el do part of that job reliably it's perfectly
fine to go that way.
Sebastian
next prev parent reply other threads:[~2010-10-04 3:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-02 3:51 Testing --- again Sebastian Rose
2010-10-02 8:09 ` Carsten Dominik
2010-10-02 14:53 ` Sebastian Rose
2010-10-02 15:01 ` Sebastian Rose
2010-10-02 17:05 ` Carsten Dominik
2010-10-02 18:12 ` Eric Schulte
2010-10-02 19:33 ` Sebastian Rose
2010-10-02 20:30 ` Eric Schulte
2010-10-02 21:55 ` Eric Schulte
2010-10-03 0:46 ` Sebastian Rose
2010-10-04 1:26 ` Eric Schulte
2010-10-04 3:59 ` Sebastian Rose [this message]
2010-10-04 15:26 ` Eric Schulte
2010-10-05 0:21 ` Sebastian Rose
2010-10-05 18:57 ` Eric Schulte
2010-10-06 0:48 ` Bernt Hansen
2010-10-06 2:57 ` Eric Schulte
2010-10-02 22:14 ` Sebastian Rose
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tyl2vc9t.fsf@gmx.de \
--to=sebastian_rose@gmx.de \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).