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.
Robby Russell 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.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks