[racket-dev] A standard for testing Racket's libraries?

On Wed, Feb 27, 2013 at 1:36 PM, Robby Findler
<robby at 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.