I have a rake task that lunches all my unit tests. The execution of
those tests may take over 20 mins. I would like to have two rake task,
one that executes a set of quick tests and one that executes all the
tests that will be executed in a nightly build.
For the moment I create a test suite that run all the TestCase methods
that its name finishes by _long.
Exemple:
class MyTest < Test::Unit::TestCase
This test is executed only in the nightly build
def test_one_long
sleep(3600)
end
This test will be executed with the quick test task and in the
nightly build
def test_two
sleep(0.4)
end
end
Does anybody have a better idea? Is there some tool that can optimize
the tests covering ?
Martin M. wrote:
I have a rake task that lunches all my unit tests. The execution of
those tests may take over 20 mins. I would like to have two rake task,
one that executes a set of quick tests and one that executes all the
tests that will be executed in a nightly build.
For the moment I create a test suite that run all the TestCase methods
that its name finishes by _long
To run only the long ones, I’d do this:
rake test TESTOPTS=-n/_long$/
Note that’s selects for long cases, and we need another Regexp that only
selects fast tests. One bug in all Regexps is they are infernally hard
to
negate. Regexps rely on their host language to call !~, instead of
simply
providing a negator. So you could put together some negator for _long$
from
primitives, but I suspect you can’t just call something simple, like
!(_long$). I hope to be corrected here!
Next, the point of test suites (the things that inherit <
Test::Unit::TestCase) is to categorize your cases by their test
situations.
Not necessarily to categorize them by their targets. You should put
all
the long tests into a big suite, SlowSuite, and then flag it like this:
if ENV.has_key? ‘slow’
class SlowSuite < Test::Unit::TestCase
…
end
end
Then you just call ‘slow=true rake test’, or ‘rake slow=true test’, to
also
get the slow ones.
Next, long tests are a symptom of insufficient decoupling. If your
tests, in
TDD terms, are helping force your dependencies apart, then new tests
should
usually be narrower and faster than old ones. Not flabbier and slower. I
get
back to you when I fully obey this advice myself!
On Sep 30, 2007, at 14:44 , Martin M. wrote:
I have a rake task that lunches all my unit tests. The execution of
those tests may take over 20 mins. I would like to have two rake
task,
one that executes a set of quick tests and one that executes all the
tests that will be executed in a nightly build.
If your tests take twenty minutes, they aren’t unit tests. Unit
tests are fast because they only test a unit.
What is it that makes them take 20 minutes or more?
Thank you for your advices, it will be of a great help.
Eric H. wrote:
On Sep 30, 2007, at 14:44 , Martin M. wrote:
I have a rake task that lunches all my unit tests. The execution of
those tests may take over 20 mins. I would like to have two rake
task,
one that executes a set of quick tests and one that executes all the
tests that will be executed in a nightly build.
If your tests take twenty minutes, they aren’t unit tests. Unit
tests are fast because they only test a unit.
What is it that makes them take 20 minutes or more?
In fact I use unit testing to test a Ruby wapper over a C++ tool that
that takes a long time to execute. In fact it is not for testing the C++
app but to test the wrapper.
I also use it to test our VC++ build and packaging system. Even if I
made small unit test, the whole process takes up to 13 mins.
On Oct 1, 2007, at 05:11 , Martin M. wrote:
tests are fast because they only test a unit.
What is it that makes them take 20 minutes or more?
In fact I use unit testing to test a Ruby wapper over a C++ tool that
that takes a long time to execute. In fact it is not for testing
the C++
app but to test the wrapper.
I also use it to test our VC++ build and packaging system. Even if I
made small unit test, the whole process takes up to 13 mins.
If you only want to test the wrapper you should stub out the C++
app’s behaviors and use those stubs instead of the real thing. You
don’t specify if this is a command-line wrapper or a ruby extension,
the former will be mork work than the latter 
For a full integration test you can use the same tests with the real
app (which will take the full amount of time).
Eric H. wrote:
If you only want to test the wrapper you should stub out the C++
app’s behaviors and use those stubs instead of the real thing. You
don’t specify if this is a command-line wrapper or a ruby extension,
the former will be mork work than the latter
For a full integration test you can use the same tests with the real
app (which will take the full amount of time).
In fact it is a command line application. I think it is a good idea to
stub it. I think I will do a small ruby script that generates an output
that is similar to c++ application.
Martin