running a unit test over and over in script/console

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. 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?

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?

Andrew Arrow 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 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?

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.

Best,

Andrew Arrow 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 about

This 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.

Best,

You should look into using autotest for this.

http://ph7spot.com/articles/getting_started_with_autotest

Robby Russell wrote:

You should look into using autotest for this.

http://ph7spot.com/articles/getting_started_with_autotest

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.