[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: `make check` mechanics

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2001-06-18 22:46:28 CEST

On Mon, Jun 18, 2001 at 03:02:15PM -0500, Karl Fogel wrote:
> I think your proposals sound good; would like to see if Kevin, Greg,
> or anyone else has anything to say about it (knowing that Greg Stein
> came back from his exotic weekend getaway today, he may not have seen
> this mail yet).

Well, since I haven't had an exotic weekend getaway, I have seen it.
It is fine with me to do this. I just pointed out before that there
was a valid reason why those tests couldn't find things relative to
themselves.

The only thing I have against this plan to internalize everything is
that it makes testing harder. We can no longer test small peices of
functionality as easily. For example, we can't have a small
repository already in existence and check something out of it.
Instead we have to 1) create a repository, 2) add something to it, 3)
check it back out somewhere else.

The reason I point this out is that if such a test fails, it can be
harder to track down exactly where the bug is. Also having more test
code per test means there is a larger chance of bugs in the test
code. There's nothing I hate more than spending weeks chasing down
the reason a test is failing to discover that it is a faulty test!

All that aside, I am fine with removing the args from the tests.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:32 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.