I am working through the Everyday Scripting With Ruby book and am trying
to run assertion tests in irb.
If I type in:
irb(main):005:0> require ‘test/unit’
=> true
As you can see above it returns true. I am assuming that this will load
the unit test methods in irb. However, if I type in an assertion test
as follows:
irb(main):006:0>
assert_equal(‘2005-03-4’,svn_date(Time.local(2005,3,4)))
NoMethodError: undefined method `assert_equal’ for main:Object
from (irb):6
from :0
It fails as above.
I have also tried to use the load command as:
load “Test::Unit” but that does not seem to work either. See below:
irb(main):008:0> load “Test::Unit”
LoadError: no such file to load – Test::Unit
from (irb):8:in `load’
from (irb):8
from :0
What do I need to do to get the assertion methods working in irb?
Thanks.
Bharat
On 2/19/07, Bharat R. [email protected] wrote:
I am working through the Everyday Scripting With Ruby book and am trying
to run assertion tests in irb.
If I type in:
irb(main):005:0> require ‘test/unit’
=> true
As you can see above it returns true. I am assuming that this will load
the unit test methods in irb. However, if I type in an assertion test
as follows:
No. It loads the Test::Unit framework. This gives you
Test::Unit::TestCase (the class where you use unit test assertions),
but you can include the assertions anywhere:
include Test::Unit::Assertions
That will include them in Object and you can use them that way.
I’m not sure I recommend this, though.
-austin
Hello Austin,
You wrote:
include Test::Unit::Assertions
That will include them in Object and you can use them that way.
I’m not sure I recommend this, though.
-austin
I did that and it works! Thanks. Why are you saying that you have
doubts about recommending something that gets the job done?
I have a side question. I am not sure when to use:
- load
- require
- include
it irb. Can someone give a simple set of guidelines for that?
Thanks.
Bharat
Bharat R. schrieb:
I have a side question. I am not sure when to use:
- load
- require
- include
it irb. Can someone give a simple set of guidelines for that?
Bharat, in addition to what Aur said, let me explain it again:
#require looks for a file in the Ruby load path and executes it, if it
hasn’t done so already. This is the normal way to load libraries.
#load is rarely used, as Aur said. The main difference to #require is
that the file is executed everytime the #load method is called, not only
the first time.
The files executed with #require and #load normally define or extend
classes and modules.
#include allows you to include the methods of modules into your
current class. Often the included modules come from previously required
files, so you often see a sequence like this:
require
class MyClass
include
end
Regards,
Pit
SonOfLilit wrote:
Things that work don’t necessarily mean good design.
load is rarely used, require is to include libraries or code files,
include is to mixin a module and has nothing to do with the previous
two.
Plug: The RubyMentor project is looking for people to help!
http://rubymentor.rubyforge.org/wiki/wiki.pl?HomePage
Ok, then there has to be “recommended” way to “invoke” the unit testing
functionality in irb. I find irb extremely useful in learning ruby.
Also, I am loading file(s) in irb all the time, so “load is rarely used”
does not make much sense to me. perhaps you meant to say that “load” is
rarely used in a regular script? Also, I am a bit puzzled over why I
cannot “load” a ruby built-in fuctionality into irb (such as unit
testing). Note that I don’t have a particular preference for using load
versus require. However, to me, load seems to work better in irb and
require is what I use in a regular script.
Please comment.
Thanks.
Bharat
Things that work don’t necessarily mean good design.
load is rarely used, require is to include libraries or code files,
include is to mixin a module and has nothing to do with the previous
two.
Plug: The RubyMentor project is looking for people to help!
http://rubymentor.rubyforge.org/wiki/wiki.pl?HomePage
On 2/19/07, Bharat R. [email protected] wrote:
include Test::Unit::Assertions
That will include them in Object and you can use them that way.
I’m not sure I recommend this, though.
-austin
I did that and it works! Thanks. Why are you saying that you have
doubts about recommending something that gets the job done?
I don’t recommend using Test::Unit assertions in IRB.
I have a side question. I am not sure when to use:
- load
This will load a Ruby source (.rb or dynamic library) regardless of
whether it’s been included before. It does not have automatic
resolution (e.g., require ‘foo/bar’ would need to be load
‘lib/foo/bar.rb’), if lib/foo/bar.rb is the appropriate relative path
from the current working directory.
- require
This will load a Ruby source once and only once. This is most common.
- include
This is the mechanism used for mixing in modules. This is wholly
unrelated to require and load.
-austin
On 2/19/07, SonOfLilit [email protected] wrote:
Things that work don’t necessarily mean good design.
load is rarely used
This is not true. It has specialized use, which is different than
“rarely used.”
Rails uses it during development mode all the time, IIRC.
-austin
I meant that #require is in general preferred over #load by
experienced ruby programmers.
On 2/19/07, Pit C. [email protected] wrote:
#include allows you to include the methods of modules into your
current class. Often the included modules come from previously required
files, so you often see a sequence like this:
require
class MyClass
include
end
Note as well that the name-of-file need not have anything to do with
the modules or classes using in the include statement.
Strictly speaking, require and load work on resources. Just because
current Ruby uses files does not mean that other mechanisms can’t be
used; some folks have extended #require with open-uri and there’s
nothing that stops anyone from looking in tar files or zip files for
files to load.
-austin
On 2/19/07, Bharat R. [email protected] wrote:
Ok, then there has to be “recommended” way to “invoke” the unit testing
functionality in irb.
Yes. The recommended way is “don’t.” Unit tests are things that are
designed to be repeatable and related to classes that you’re building.
Simply using the assertions gains you absolutely nothing with respect
to using IRB itself.
I find irb extremely useful in learning ruby.
Also, I am loading file(s) in irb all the time, so “load is rarely used”
does not make much sense to me.
Use “load” when you want to reread the classes you’re working with
from disk. Otherwise, forget that it exists.
Also, I am a bit puzzled over why I
cannot “load” a ruby built-in fuctionality into irb (such as unit
testing).
You tried “load Test::Unit” (or “load ‘Test::Unit’”); this won’t work
because load doesn’t work that way. Doing ‘load “test/unit”’ won’t
work, either, because Ruby doesn’t dynamically resolve the extension.
Doing ‘load “test/unit.rb”’ does.
Note that I don’t have a particular preference for using load
versus require.
You should.
-austin
Thank you gents. Very useful.
Regards,
Bharat
Austin Z. wrote:
On 2/19/07, Bharat R. [email protected] wrote:
Ok, then there has to be “recommended” way to “invoke” the unit testing
functionality in irb.
Yes. The recommended way is “don’t.” Unit tests are things that are
designed to be repeatable and related to classes that you’re building.
Simply using the assertions gains you absolutely nothing with respect
to using IRB itself.
Agreed. Besides, it’s often simpler to write:
raise unless foo == bar
than it is to use Test::Unit’s assertions:
assert_equal foo, bar # is it foo, bar or bar, foo? I always forget
On 2/19/07, Bharat R. [email protected] wrote:
Hello Suraj,
Thanks for the info. I was more interested in being able to use the
full compliments of Assert functionality in irb and just not the
equality test. raising exception is an interesting twist however.
What are you actually trying to do, Bharat?
It really seems to me that you’re approaching this backwards.
-austin
Hello Suraj,
Thanks for the info. I was more interested in being able to use the
full compliments of Assert functionality in irb and just not the
equality test. raising exception is an interesting twist however.
Regards,
Bharat
On 2/19/07, Bharat R. [email protected] wrote:
Please see my more recent post about “IRB Power User’s Guide”. I learn
more by “hacking” than any other way. IRB seems like an ideal way to
hack.
It is; I have recently edited several thousand MP3s quickly, easily, and
safely using irb. It is not, however, a full “image” environment
(although add-on tools like Wirble help significantly). However, to edit
those MP3s, I spent time working on file-based scripts that reloaded
themselves in irb to give myself a base environment.
irb only goes so far in understanding Ruby. For the rest, use scripts.
-austin
Hello Austin,
Please see my more recent post about “IRB Power User’s Guide”.
I learn more by “hacking” than any other way. IRB seems like an ideal
way to hack. Actually, I have been trying various bits and pieces of
code from various books, the latest being “Everyday Scripting with
Ruby”. Seems like a decent book. I was having one of those mental
disconnect moments of not being able to grasp what the author was trying
to explain in chapter 7 of his book, i.e., test driven development. In
that foggy state of mind, I started trying to type in his assertions
into the irb console to see what happens and focus my mind. Up until
now, everything that I have tried in irb usually works, but I was
stopped here due to my lack of knowledge about IRB’s capabilities. In
retrospect, as you and others are pointing out, I should probably not
try to use to the irb “hammer” to drive in every “nail” in sight.
So, in a nutshell, that was my motivation in asking this question.
Thanks a bunch though for your time and thoughtful explanations.
Regards,
Bharat
On 2/19/07, Austin Z. [email protected] wrote:
doubts about recommending something that gets the job done?
I don’t recommend using Test::Unit assertions in IRB.
If the OP wants to try out assertions in IRB, what is the problem?
Its a perfectly good way to get used to the API, the different ways
you can assert something, etc. Thats one perfectly valid way to use
IRB. If the OP asked “how do I write an automated test suite in
IRB?”, then I can see a reason for concern. =)
Bharat: a better way to use assertions inside IRB would be to create a
helper object and include them into that, and then load that into your
.irbrc. This avoids polluting the top level namespace in irb and is
recommended if you want to use assertions often in irb. For example:
class TestHelper
include Test::Unit::Assertions
end
then inside irb, you can do:
test_helper = TestHelper.new
test_helper.assert_equal(4, 2+2)
Rob S. wrote:
On 2/19/07, Austin Z. [email protected] wrote:
doubts about recommending something that gets the job done?
I don’t recommend using Test::Unit assertions in IRB.
If the OP wants to try out assertions in IRB, what is the problem?
Its a perfectly good way to get used to the API, the different ways
you can assert something, etc. Thats one perfectly valid way to use
IRB. If the OP asked “how do I write an automated test suite in
IRB?”, then I can see a reason for concern. =)
Bharat: a better way to use assertions inside IRB would be to create a
helper object and include them into that, and then load that into your
.irbrc. This avoids polluting the top level namespace in irb and is
recommended if you want to use assertions often in irb. For example:
class TestHelper
include Test::Unit::Assertions
end
then inside irb, you can do:
test_helper = TestHelper.new
test_helper.assert_equal(4, 2+2)
Just what the doctor ordered! This is what I call: have your cake and
eat it too! Works! Go IRB!!!
Thanks Rob.
Regards,
Bharat