From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Re: Testing --- again... Date: Mon, 04 Oct 2010 09:26:51 -0600 Message-ID: <8739sm6ksk.fsf@gmail.com> References: <87vd5li75s.fsf@gmx.de> <0CDCC1C3-3D93-465E-827C-A722978F4D13@gmail.com> <87fwwoihuy.fsf@gmail.com> <87fwwobd9k.fsf@gmx.de> <871v88ibhh.fsf@gmail.com> <87sk0ofef3.fsf@gmail.com> <87ocbbvuig.fsf@gmx.de> <87vd5ibve8.fsf@gmail.com> <87tyl2vc9t.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=56643 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P2mwP-00057z-C4 for emacs-orgmode@gnu.org; Mon, 04 Oct 2010 11:27:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P2mwN-0005wk-IU for emacs-orgmode@gnu.org; Mon, 04 Oct 2010 11:27:01 -0400 Received: from mail-iw0-f169.google.com ([209.85.214.169]:39460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P2mwN-0005wR-Be for emacs-orgmode@gnu.org; Mon, 04 Oct 2010 11:26:59 -0400 Received: by iwn36 with SMTP id 36so185996iwn.0 for ; Mon, 04 Oct 2010 08:26:58 -0700 (PDT) In-Reply-To: <87tyl2vc9t.fsf@gmx.de> (Sebastian Rose's message of "Mon, 04 Oct 2010 05:59:26 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Sebastian Rose Cc: Emacs-orgmode mailing list , Carsten Dominik 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 writes: > "Eric Schulte" 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 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