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:innew’
from C:/RubyWorkspace/LogIn.rb:27:in `’

-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… :confused:

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.

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' orrequire_relative’).

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… :confused:

I’m kind of new to using test/unit ( and Ruby! :slight_smile: ), 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

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' orrequire_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. [email protected] 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

That’s davetron1000 :slight_smile:

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

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

On Jan 4, 2013, at 8:24 PM, D. Deryl D. 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

On Fri, Jan 4, 2013 at 9:45 PM, Derrick B. [email protected] 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).

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 D. (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 P.ming 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,

Am 05.01.2013 16:45, schrieb tamouse mailing lists:

On Fri, Jan 4, 2013 at 9:45 PM, Derrick B. [email protected] 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. [email protected] 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. :slight_smile:

On Sat, Jan 5, 2013 at 9:45 AM, tamouse mailing lists
[email protected] 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… :stuck_out_tongue:

On Sat, Jan 5, 2013 at 11:06 AM, Derrick B. [email protected]
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. :slight_smile:

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

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. [email protected] 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.