On Wed, Feb 27, 2013 at 1:36 PM, Robby Findler
<ro...@eecs.northwestern.edu> wrote:
> I think that currently you can look at what drdr does. That's the best we
> have.
I'll assume that this is the drdr collection in meta,
http://git.racket-lang.org/plt/tree/HEAD:/collects/meta/drdr
and not the drdr2 directory, right?
> Meanwhile, I think that if you are willing to live a bit on the edge, you
> can try to run some reasonable looking tests (break something intentionally
> and make sure they complain, say) and then go ahead and push and let drdr
> sort things out more. Worst comes to worst, you just revert a commit and try
> again tomorrow, no?
I am somewhat risk averse. "Skittish" is probably apt. I'd prefer to
rerun re-run a collection-wide test immediately after a bug fix, while
the change is still fresh in my mind. Some collections are harder to
test this way, so DrDr plays its role, but for algorithmic or
data-structure stuff, I should be able to easily run the tests that I
can execute locally, before committing a patch to the central
repository.
I can already do this, by spending time reading through the collection
tree till I find the modules that drive the unit tests. Sometimes I
do a manual "grep -r" for the word 'test' and hope for the best. I
just wish I didn't have to do that manual search. And I sometimes get
it wrong; e.g. the datalog thing from a day ago: I was testing a
change to parser-tools, but couldn't find any tests for the
parser-tools collection. The next best thing I could do was run tests
on the collections that _use_ parser-tools, and that's how this topic
got started.
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
