From: "Eric Schulte" <schulte.eric@gmail.com>
To: Sebastian Rose <sebastian_rose@gmx.de>
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 09:26:51 -0600 [thread overview]
Message-ID: <8739sm6ksk.fsf@gmail.com> (raw)
In-Reply-To: <87tyl2vc9t.fsf@gmx.de> (Sebastian Rose's message of "Mon, 04 Oct 2010 05:59:26 +0200")
Hi,
So, I've been using the framework in the combined-testing branch this
morning writing tests to strap down my daily Babel bug fixes, and I'm
really liking ERT.
I wonder, can we commit to the combined-testing branch, and if so could
we fold it into the master branch? It would make my test driven bug
fixing a much smoother process, and would remove the need to rebase the
combined-testing branch against master and "git push -f" the changes up
to repo.or.cz which just feels wrong.
Thoughts?
-- Eric
Sebastian Rose <sebastian_rose@gmx.de> writes:
> "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 15:27 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
2010-10-04 15:26 ` Eric Schulte [this message]
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=8739sm6ksk.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=sebastian_rose@gmx.de \
/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).