I started doing this:
$ RAILS_ENV=test script/console
load ‘test/unit/models/example_test.rb’; r = Test::Unit::TestResult.new; reload!; ExampleTest.new(:test_example1).run® { |c,v| }; pp results
and then just hit up arrow and run that same line again over and over in
script/console. That way I can make changes to the test and app code,
and don’t have to wait for rails startup each time.
Does that make sense to others? I’m a missing something that will make
this a bad way to run a test?
Andrew A. wrote:
I started doing this:
$ RAILS_ENV=test script/console
load ‘test/unit/models/example_test.rb’; r = Test::Unit::TestResult.new; reload!; ExampleTest.new(:test_example1).run(r) { |c,v| }; pp results
and then just hit up arrow and run that same line again over and over in
script/console.
If you’re going to do that, then it’s probably better to declare a
function that will do all that so you don’t have to rely on the up-arrow
key. But why not just use autotest?
That way I can make changes to the test and app code,
and don’t have to wait for rails startup each time.
Depending on what you’re changing, you may well want to restart Rails
each time to ensure that it’s loading current code.
Does that make sense to others? I’m a missing something that will make
this a bad way to run a test?
Well, you may not be getting good test isolation – there’s the
potential for old test runs to influence new ones. And it’s more work
than it has to be – autotest will do the same thing without you even
needing to press a key. What’s more, it will test a subset of the code
first to save time. I guess I just don’t see why not use autotest.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Marnen Laibow-Koser wrote:
If you’re going to do that, then it’s probably better to declare a
function that will do all that so you don’t have to rely on the up-arrow
key. But why not just use autotest?
Sure, I can make it easier with a function, that was just the first
version I got working.
As I understand it, autotest runs each test normally, by starting up a
new rails environment. It takes over 10 seconds for our rails
environment to start. (We’ve tried to get it to start quicker, but
that’s a whole other topic.) I need to be able to make a change to a
test or code and run the test immediately without the 10 second wait.
Depending on what you’re changing, you may well want to restart Rails
each time to ensure that it’s loading current code.
That’s what I’m trying to avoid. That’s what the load and reload!
commands are hopefully doing.
Well, you may not be getting good test isolation – there’s the
potential for old test runs to influence new ones. And it’s more work
I’m only running 1 test in the above example, “test_example1”. And I
instantiate a new ExampleTest each time. How could this lead to and old
test influencing a new one?
I’ll have to check on this, but I don’t think that reload! reloads the
whole environment – which is probably why you don’t get the 10-second
It doesn’t reload stuff like route changes or changes to environmnet.rb,
but that’s okay. It does reload stuff like changes to any classes in
app/*.
If your old test has side effects (such as DB operations!) that are not
cleaned up, then it will influence the new test. It’s not just about
This is for unit tests only, no DB access.
I agree that reloading the environment can sometimes ve a bit slow. But
you’ve got to do it if you want reliable tests.
I disagree. I think 10 seconds is completely un-acceptable to do proper
test-driven development. Since using this new system I write much
better unit tests because I have the freedom to run it over and over and
over after every small change.
Just like you don’t have to start and stop your webserver when making
changes in development mode. Rails nicely has a setting to only cache
classes in production mode. So you make a change, and can refresh the
browser and see it right away. I want that same freedom in tests.
Because that’s what makes me NOT want to write the test. Because I know
I can see the change right away in the browser.
Here’s is the logic cleaned up and in a function:
def reload_and_run_unit_test(test_path, test)
load “test/unit/#{test_path}_test.rb”
reload!
klass = “#{test_path.split(’/’).last.titleize.gsub(/ /,
‘’)}Test”.constantize
suite = Test::Unit::TestSuite.new(klass.to_s)
suite << klass.new(test)
runner = Test::Unit::UI::Console::TestRunner.new(suite)
runner.start
‘’
end
Andrew A. wrote:
[…]
Depending on what you’re changing, you may well want to restart Rails
each time to ensure that it’s loading current code.That’s what I’m trying to avoid. That’s what the load and reload!
commands are hopefully doing.
I’ll have to check on this, but I don’t think that reload! reloads the
whole environment – which is probably why you don’t get the 10-second
wait. You need to reload the environment to ensure that the code you’re
testing is in a consistent state; otherwise, you might make changes to
your environment files that break your code, but you’d never know it.
Well, you may not be getting good test isolation – there’s the
potential for old test runs to influence new ones. And it’s more workI’m only running 1 test in the above example, “test_example1”. And I
instantiate a new ExampleTest each time. How could this lead to and old
test influencing a new one?
If your old test has side effects (such as DB operations!) that are not
cleaned up, then it will influence the new test. It’s not just about
instantiating a new test object: to get good isolation you basically
have to have a pristine environment and DB, which is why autotest does
what it does.
I agree that reloading the environment can sometimes ve a bit slow. But
you’ve got to do it if you want reliable tests.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Andrew A. wrote:
It doesn’t reload stuff like route changes or changes to environmnet.rb,
but that’s okay.
It’s only OK if you’re absolutely 100% certain that you’ll never change
any routes or environment values in the course of your test code.
[…]
If your old test has side effects (such as DB operations!) that are not
cleaned up, then it will influence the new test. It’s not just aboutThis is for unit tests only, no DB access.
I used DB access as a common example, not as the only thing. Basically,
if your test could change system state at all, then you need to start
from scratch each time.
I agree that reloading the environment can sometimes ve a bit slow. But
you’ve got to do it if you want reliable tests.I disagree. I think 10 seconds is completely un-acceptable to do proper
test-driven development.
That may be, but you’ve still got to do it. If you don’t like the time
delay, fix it (perhaps you can shrink what your environment files do?).
Since using this new system I write much
better unit tests because I have the freedom to run it over and over and
over after every small change.
But you don’t know whether your tests are properly isolated, and
therefore they are not reliable.
Just like you don’t have to start and stop your webserver when making
changes in development mode.
You do have to start and stop it if you change the environment files.
So you make a change, and can refresh the
browser and see it right away. I want that same freedom in tests.
Autotest will give you that, if you can lick the problem with the slow
load time. Perhaps the ZenTest developers would have some good ideas?
Because that’s what makes me NOT want to write the test. Because I know
I can see the change right away in the browser.
Sure you can, but without tests, how do you know it really does what you
expect? It’s considerations like that that keep me writing tests.
I understand what you’re trying to do here, and I sympathize. But I
think it’s unreasonable to expect that you can do any sort of acceptable
unit testing without reloading the environment.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Robby R. wrote:
You should look into using autotest for this.
Thanks Robby, but that doesn’t solve the problem of loading the rails
environment. I want to change a test and get instant feedback on it’s
run. Even autotest will have to wait for the rails environment to load.
You should look into using autotest for this.
http://ph7spot.com/articles/getting_started_with_autotest
On Wed, Jul 8, 2009 at 11:59 AM, Andrew
Arrow[email protected] wrote:
Does that make sense to others? Â I’m a missing something that will make
this a bad way to run a test?Posted via http://www.ruby-forum.com/.
–
Robby R.
Chief Evangelist, Partner
PLANET ARGON, LLC
design // development // hosting w/Ruby on Rails
http://robbyonrails.com/
http://twitter.com/planetargon
aim: planetargon
+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs