Forum: Ruby require "test/unit"

Hi,

When i run my script without require "test/unit" it runs well. But i
have noticed that many use require "test/unit" and <
Test::Unit::TestCase in theirs scripts. So i just added it to see whats
happens but it complains about wrong number of arguments. Do someone
have any knowledge or url that it explains it for me?

-error output-
C:/Ruby193/lib/ruby/1.9.1/minitest/unit.rb:971:in `initialize': wrong
number of arguments (0 for 1) (ArgumentError)
        from C:/RubyWorkspace/LogIn.rb:27:in `new'
        from C:/RubyWorkspace/LogIn.rb:27:in `<main>'


-Code: Wrong number of arguments-
require "selenium-webdriver"
require "test/unit"
class LogIn < Test::Unit::TestCase
...
end

-Code: works-
require "selenium-webdriver"
class LogIn
...
end

Best Regards
Mattias

Did you saw the Ruby documentation? either test::unit and minitest are 
documented, they come in the Ruby pack.

Hi Damián M. González!

Tanks for your reply, i have found below but it do not answer my 
question or I do not know how to read/use it.. :/

class Test::Unit::TestCase
In Files
lib/minitest/unit.rb
lib/test/unit/parallel.rb
lib/test/unit/testcase.rb
Parent
MiniTest::Unit::TestCase

Included Modules
Test::Unit::Assertions
Public Class Methods
test_order() click to toggle source
# File lib/test/unit/testcase.rb, line 20
def self.test_order
  :sorted
endPublic Instance Methods
on_parallel_worker?() click to toggle source
# File lib/test/unit/parallel.rb, line 149
def on_parallel_worker?
  true
endrun(runner) click to toggle source
# File lib/test/unit/testcase.rb, line 15
def run runner
  @options = runner.options
  super runner
endGenerated by RDoc 3.12.

Generated with the Darkfish Rdoc Generator 3.

Mattias A. wrote in post #1090700:
> Hi Damián M. González!
>
> Tanks for your reply, i have found below but it do not answer my
> question or I do not know how to read/use it.. :/
>

I'm kind of new to using test/unit ( and Ruby!  :)  ), but I was getting
that same error, too.  What I discovered was just adding a test class to
my existing code caused that error until I stripped the code down to
just classes.  For example, I wrote a simple Calculator class with four
methods (add, subtract, multiply, divide).  I then added code for it to
be interactive.  I had to then remove that extra code so that my file
contains only the Calculator class and the TestClass, which included the
test cases, then it worked.

So, I think (and I am guessing here) that your test files should only
include classes to be tested and the actual testing class.  That would
make sense, because when testing code, you are mainly concerned with
static test cases which cover all possible execution paths, so why
bother with user interaction.

Here are the two files, the original and the one modified for testing:

######## Original #################
class Calculator
  def initialize(a, b)
    @a, @b = a, b
  end
  def add
    @a + @b
  end
  def sub
    @a - @b
  end
  def mul
    @a * @b
  end
  def div
    return "undef" if @b == 0
    @a / @b
  end
end

x, y = ARGV[0].to_i, ARGV[1].to_i
if ARGV.length == 0
  print "Usage calc 3 4\n"
  exit
end
c = Calculator.new( x, y )
puts "#{x} plus #{y} equals: #{c.add}"
puts "#{x} minus #{y} equals: #{c.sub}\n"
puts "#{x} times #{y} equals: #{c.mul}\n"
puts "#{x} divided by #{y} equals: #{c.div}\n"


######## For Testing #################
require 'test/unit'

class Calculator
  def initialize(a, b)
    @a, @b = a, b
  end
  def add
    @a + @b
  end
  def sub
    @a - @b
  end
  def mul
    @a * @b
  end
  def div
    return "undef" if @b == 0
    @a / @b
  end
end

class TestClass < Test::Unit::TestCase
  def test_add
    c = Calculator.new( 12, 3 )
    assert_equal 15, c.add
  end
  def test_sub
    c = Calculator.new( 12, 3 )
    assert_equal 9, c.sub
  end
  def test_mul
    c = Calculator.new( 12, 3 )
    assert_equal 36, c.mul
  end
  def test_div
    c = Calculator.new( 12, 3 )
    assert_equal 4, c.div
  end
end

#########  Output  ##########
edited to add Output:

Run options:

# Running tests:

....

Finished tests in 0.000000s, Inf tests/s, Inf assertions/s.

4 tests, 4 assertions, 0 failures, 0 errors, 0 skips

Am 04.01.2013 19:48, schrieb Derrick B.:
> So, I think (and I am guessing here) that your test files should only
> include classes to be tested and the actual testing class.  That would

Defining the class to be tested in the test file does not make
any sense, since you want to use your class elsewhere, and not only
in tests. You would define it in a separate file and require it
(with `require' or `require_relative').

unknown wrote in post #1091069:
> Am 04.01.2013 19:48, schrieb Derrick B.:
>> So, I think (and I am guessing here) that your test files should only
>> include classes to be tested and the actual testing class.  That would
>
> Defining the class to be tested in the test file does not make
> any sense, since you want to use your class elsewhere, and not only
> in tests. You would define it in a separate file and require it
> (with `require' or `require_relative').

You're right, I should not have stated that in that way, but my main 
point was directly related to how I thought the OP was adding the test 
class into the current code, and not separately.  He was receiving an 
error, which I also encountered, so I gave my solution.

Thank you for the clarification on proper test class usage.  It should 
help me, and the OP, to steer away from such errors by separating the 
code.

On Fri, Jan 4, 2013 at 2:07 PM, Derrick B. <lists@ruby-forum.com> wrote:
> You're right, I should not have stated that in that way, but my main
> point was directly related to how I thought the OP was adding the test
> class into the current code, and not separately.  He was receiving an
> error, which I also encountered, so I gave my solution.
>
> Thank you for the clarification on proper test class usage.  It should
> help me, and the OP, to steer away from such errors by separating the
> code.

There is a structure for building command-line applications that may
be something you want to adopt.

I'm going to point you to davetron1000's gems: methadone and GLI, both
of which are builders for command-line apps (kind of like rails is for
web apps). They provide some nifty things for making nice CLI apps,
but possibly the tl;dr is that you implement the bare minimum in the
part that does the part to take arguments from the command line, and
then pass them to your classes/modules/etc, which are in separate
files.

Generally, a CLI app structure looks like this:

my_cli_app/
  Gemfile
  Rakefile
  bin/
    my_cli_app # this contains the command line interaction part
  lib/
    my_cli_app/ # these implement specific features of the module/class
      version.rb
      classOne.rb
      ...
    my_cli_app.rb # this implements the module/class
  my_cli_app.gemspec # describes how to build this gem
  README.rdoc # application documentation that gets bundled in rdoc
  spec/ # rspec tests for the app's classes
  test/ # Test::Unit tests for app's classes

(and if you're awesome)

  feature/ # cucumber/aruba tests for the app

I would also recommend you get the book called Build Awesome
Command-Line Applications in Ruby, by David Bryant Copeland. Excellent 
book!

> part that does the part to take arguments from the command line, and
> lib/
> (and if you're awesome)
>
> in tests. You would define it in a separate file and require it
> methods (add, subtract, multiply, divide). I then added code for it to
> Here are the two files, the original and the one modified for testing:
> @a - @b
> x, y = ARGV[0].to_i, ARGV[1].to_i
>
> def sub
>
> c = Calculator.new( 12, 3 )
> Hi Damián M. González!
> MiniTest::Unit::TestCase
> # File lib/test/unit/parallel.rb, line 149
>
--
D. Deryl Downey

"The bug which you would fright me with I seek" - William Shakespeare - 
The Winter's Tale, Act III, Scene II - A court of Justice.

That's davetron1000 :)

On Jan 4, 2013, at 8:24 PM, D. Deryl Downey wrote:

> I would also recommend you get the book called Build Awesome Command-Line 
Applications in Ruby, by David Bryant Copeland. Excellent book!

Just bought this book myself recently. Just haven't had a whole lot of 
time to read it. But what I did read, I thought was very well thought 
out.

Wayne

Posted by tamouse mailing lists (Guest) on 2013-01-05 03:22
>
> There is a structure for building command-line applications that may
> be something you want to adopt.
>
> I'm going to point you to davetron1000's gems: methadone and GLI, both
> of which are builders for command-line apps (kind of like rails is for
> web apps). They provide some nifty things for making nice CLI apps,
> but possibly the tl;dr is that you implement the bare minimum in the
> part that does the part to take arguments from the command line, and
> then pass them to your classes/modules/etc, which are in separate
> files.
>

Posted by D. Deryl Downey (ddd) on 2013-01-05 03:25
> I would also recommend you get the book called Build Awesome
> Command-Line Applications in Ruby, by David Bryant Copeland. Excellent
> book!

Thanks!  This is all good information, but I feel I need to improve my
Ruby basics first before learning to use these frameworks.  I will
install them to at least take a peek, though.

I have been reading "The Ruby Programming Language", "Programming Ruby"
(1.8 edition), "Everyday Scripting with Ruby", and have "The Well
Grounded Rubyist" on the way.  I like the "Everyday..." book, because it
gets right into script creation through testing, which should be useful
for my Perl side, too.

Thanks again,

On Fri, Jan 4, 2013 at 9:45 PM, Derrick B. <lists@ruby-forum.com> wrote:
> Thanks!  This is all good information, but I feel I need to improve my
> Ruby basics first before learning to use these frameworks.  I will
> install them to at least take a peek, though.

There is much much more to programming that learning a bit of syntax.
Learning *how* to structure and write the kinds of applications you
want now is going to serve you as you progress.

Let me offer an analogy of sorts:

Say you want to learn how to drive. In addition to learning how to use
the accelerator, the brake, the clutch, the stearing wheel, turn
signals, etc. (the syntax, so to speak), you need to learn where to
find your keys, where the car is parked, how to open the garage door,
how to read a map to find out where you're going, how to obey street
signs and lights, which side of the street to drive on, and so on (the
environment, the structure, the libraries, etc).

On Sat, Jan 5, 2013 at 9:45 AM, tamouse mailing lists
<tamouse.lists@gmail.com> wrote:
>
> Say you want to learn how to drive. In addition to learning how to use
> the accelerator, the brake, the clutch, the stearing wheel, turn

and/or steering wheel, if you're not doing things with cattle.... :P

Am 05.01.2013 16:45, schrieb tamouse mailing lists:
> On Fri, Jan 4, 2013 at 9:45 PM, Derrick B. <lists@ruby-forum.com> wrote:
>> Thanks!  This is all good information, but I feel I need to improve my
>> Ruby basics first before learning to use these frameworks.  I will
>> install them to at least take a peek, though.
>
> There is much much more to programming that learning a bit of syntax.
> Learning *how* to structure and write the kinds of applications you
> want now is going to serve you as you progress.

On the other hand, you can also get "lost" in a framework, especially
as a beginner.

For not too complex (!) tasks you can already achieve much with a
single file containing all needed classes, the optparse library and
(of course) a test file or test files
-> no need to cut a gem; easy installation (copying into search path);
    all code in one place.

I often use the following structure:

-----
#!/usr/bin/env ruby
# short description, copyright

require 'optparse'
require 'whatever'

module MyApp  # prevents name clashes

   # constants and class definitions
   # ...
   # ...
   # ...

   class Application
     # provides a run! method
   end


   if __FILE__ == $0
     Application.new.run!  # not called if file is required (by tests)
   end

end  # of module

tamouse mailing lists wrote in post #1091138:
> On Fri, Jan 4, 2013 at 9:45 PM, Derrick B. <lists@ruby-forum.com> wrote:
>> Thanks!  This is all good information, but I feel I need to improve my
>> Ruby basics first before learning to use these frameworks.  I will
>> install them to at least take a peek, though.
>
> There is much much more to programming that learning a bit of syntax.
> Learning *how* to structure and write the kinds of applications you
> want now is going to serve you as you progress.
>
> Let me offer an analogy of sorts:
>
> Say you want to learn how to drive. In addition to learning how to use
> the accelerator, the brake, the clutch, the stearing wheel, turn
> signals, etc. (the syntax, so to speak), you need to learn where to
> find your keys, where the car is parked, how to open the garage door,
> how to read a map to find out where you're going, how to obey street
> signs and lights, which side of the street to drive on, and so on (the
> environment, the structure, the libraries, etc).

Thanks, but this isn't my first time at programming, just Ruby.  So, it 
kind of feels like an overall lecture on how to program, which is not 
very helpful.  :)

unknown wrote in post #1091145:
> Am 05.01.2013 16:45, schrieb tamouse mailing lists:
>> On Fri, Jan 4, 2013 at 9:45 PM, Derrick B. <lists@ruby-forum.com> wrote:
>>> Thanks!  This is all good information, but I feel I need to improve my
>>> Ruby basics first before learning to use these frameworks.  I will
>>> install them to at least take a peek, though.
>>
>> There is much much more to programming that learning a bit of syntax.
>> Learning *how* to structure and write the kinds of applications you
>> want now is going to serve you as you progress.
>
> On the other hand, you can also get "lost" in a framework, especially
> as a beginner.
>
> For not too complex (!) tasks you can already achieve much with a
> single file containing all needed classes, the optparse library and
> (of course) a test file or test files
> -> no need to cut a gem; easy installation (copying into search path);
>     all code in one place.
>
> I often use the following structure:
>
> -----
> #!/usr/bin/env ruby
> # short description, copyright
>
> require 'optparse'
> require 'whatever'
>
> module MyApp  # prevents name clashes
>
>    # constants and class definitions
>    # ...
>    # ...
>    # ...
>
>    class Application
>      # provides a run! method
>    end
>
>
>    if __FILE__ == $0
>      Application.new.run!  # not called if file is required (by tests)
>    end
>
> end  # of module

You know, for the longest time I keep telling myself I need to create 
template files for whatever language I feel like programming in that 
week, and never do it.  I just keep jumping and start writing.  One of 
these days!  heh

I installed methadone and it reminds me of Perl's Module::Starter, which 
I am currently playing around with.  It appears to create almost an 
exact type of file/directory structure to then fill in your code and 
documentation.  Very nice.

On Sat, Jan 5, 2013 at 11:06 AM, Derrick B. <lists@ruby-forum.com> 
wrote:
> Thanks, but this isn't my first time at programming, just Ruby.  So, it
> kind of feels like an overall lecture on how to program, which is not
> very helpful.  :)

The beauty of free, anonymous advice is that you don't have to listen to 
it.