Rails - Jul 2009 - 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?
-- 
Posted via http://www.ruby-forum.com/.

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

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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?
-- 
Posted via http://www.ruby-forum.com/.

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,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

> 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
-- 
Posted via http://www.ruby-forum.com/.

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,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
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.  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?
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>


-- 
Robby Russell
Chief Evangelist, Partner

PLANET ARGON, LLC
design // development // hosting w/Ruby on Rails

http://planetargon.com/
http://robbyonrails.com/
http://twitter.com/planetargon
aim: planetargon

+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]

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.
-- 
Posted via http://www.ruby-forum.com/.