On Sep 5, 2008, at 10:55 AM, Pat Maddox wrote:
time. Just do the math: If one database test takes 0.2 sec (a
realistic
figure), then 5 will take 1 sec, at 1000 over 3 minutes, and at
2000 over 6
minutes. This is starting to get into "time for a coffee/cigarette/
juggling
what have you" breaks. So - either you end up very hyped up on
coffee not
doing much work, or you don't run your test suite very often, which
leads to
legitimate bugs which can be solved. (At one point I had actually
deployed
code into production which had a serious bug. This all could have
been
avoided because the test suite *was failing*, but I had gotten into
the
habit of not running it because it was too expensive).
There's a couple things you can do to help with this:
* Split slow tests into another dir and run them separately from your
fast suite. Keep rspactor on your fast suite and run the slow tests
before checkin
* Use a CI server
Yes, most certainly. But the db tests •still* aren't cheap, meaning
you'll need to wait for the CI server to run them there is a failure,
or wait before checking in.
Also - have you found a CI server that is working with git?
I've been working hard on solving this issue by building a SQL
parser in
treetop, and hope anyone who is interested will join me (just let
me know if
you are interested and I'll make the project publicly viewable on
github).
http://github.com/nkallen/arel/tree/master might also be interesting
to you.
Hmm..Well, that's interesting, although I think that project, like so
many others, is *generating* SQL, not parsing it, correct?
I've made my sql parser public, and here is is if anyone wants to take
a gander (although it most certainly is still a work in progress):
http://github.com/smtlaissezfaire/guillotine/tree/master
Scott
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
