Re: Regression testing for org-mode

[Robert Goldman <rpgoldman@sift.info>]

Avdi Grimm wrote:
> On Thu, Oct 23, 2008 at 7:57 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> I'm pessimistic that the colossal amount of work involved in wrapping
>> all of org-modes extensive and varied functionality into a test
>> framework can/should actually be completed.  Would it be sufficient to
>> simply begin dealing with bug reports in a test-first manner?
> 
> Absolutely.  I do NOT recommend making an effort to get test coverage
> over existing code just for the sake of coverage - in my experience
> this usually leads a lot of work for brittle and not terribly useful
> tests.  Put tests only around the areas you are about to change.  Over
> time the coverage will grow.
> 
>> Also, should we start tracking bug reports somewhere (worg), so that
>> they can be claimed, tested against, and repaired?
> 
> Not a bad idea.  Normally I'd recommend just going with an established
> bug tracker like Trac or Lighthouse, but since Org is so great for
> managing tasks it seems only right that the developers should "eat
> their own dogfood" by using Org to track tickets :-)
> 

Actually, I'm not sure I necessarily agree with the notion of using Org
to track tickets.  The reason is not that org mightn't be up to the job,
but that the use of org with git won't be up to it.  systems like trac
and bugzilla are set up to allow outsiders to post bugs, but if we use
git, then we're really raising the bar for bug submission.  Instead of
filling out a form, a bug reporter would now have to figure out how to
use git, pull the org file, modify it, and then either push it (which
would require someone to authorize him or her) or submit it to someone
else who would push it.  That seems inappropriate to me --- when you're
developing software a good bug report is very valuable, and one
shouldn't turn them away.

Unless someone can figure out an easier way for people to submit bugs
with what worg has now, I'm inclined to say that trac or bugzilla would
be better.

Best,
r