Run only one test case?

Ruby
1

Rubies:

Here’s where I run my Ruby/Unit suite:

aTestSuite = Test::Unit::TestSuite.new("MRW")
aTestSuite << a bunch of suites
got = runner.run(aTestSuite)

Now how to augment that so we fetch ARGV[], and if there’s a test case
by
name, only run that one case?

2

Phlip wrote:

Rubies:

Here’s where I run my Ruby/Unit suite:

aTestSuite = Test::Unit::TestSuite.new("MRW")
aTestSuite << a bunch of suites
got = runner.run(aTestSuite)

Now how to augment that so we fetch ARGV[], and if there’s a test case by
name, only run that one case?

Is this what you mean?

#! /usr/bin/ruby

def exec(s)
puts “Exec #{s}”
end

if ARGV.size > 0
exec(ARGV.first)
else
exec(“something else”)
end

3

Paul L. wrote:

Phlip wrote:

Rubies:

Here’s where I run my Ruby/Unit suite:

aTestSuite = Test::Unit::TestSuite.new("MRW")
aTestSuite << a bunch of suites
got = runner.run(aTestSuite)

Now how to augment that so we fetch ARGV[], and if there’s a test case by
name, only run that one case?

Is this what you mean?

#! /usr/bin/ruby

def exec(s)
puts “Exec #{s}”
end

if ARGV.size > 0
exec(ARGV.first)
else
exec(“something else”)
end

Combine that with
Test::Unit::UI::Console::TestRunner.run(TS_MyTests)
From
http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html
And I think you can do what you want.

4

Paul L. wrote:

Is this what you mean?

No, and I don’t see any connection between it and my question.

5

Paul L. wrote:

Is this what you mean?

No, and I don’t see any connection between it and my question.

Sorry - one connection: ARGV.shift. I know that!!

6

Here’s where I run my Ruby/Unit suite:

aTestSuite = Test::Unit::TestSuite.new(“MRW”)
aTestSuite << a bunch of suites
got = runner.run(aTestSuite)

The above code runs all test cases. I want to run only one of them.

Now how to augment that so we fetch ARGV[], and if there’s a test case by
name, only run that one case?

Suppose one of them is called test_readMyPost. Can I run it like this?

got = runner.run(aTestSuite, ‘test_readMyPost’)

Alternately, could I loop thru aTestSuite’s cases, find it, and run it?

(I’m not asking how to run test suites, or how to parse command line
arguments here!)

7

Rubies:

Here’s a normal example of running a Ruby/Unit suite:

aTestSuite = Test::Unit::TestSuite.new("MRW")
aTestSuite << a bunch of suites
got = runner.run(aTestSuite)

The above code runs all test cases. I want to run only one of them.

A “test suite” is (generally) a list of test cases. Here, it is a list
of
lists of test cases. Running only one *.rb file would run all cases in
that
file’s suites. I want to run only one test case. Here are three test
cases:

class SomeSuite < Test::Unit::TestCase

def test_runThisCase()
   #...
end


def test_dontRunThis()
   #...
end

def test_orThis()
   #...
end

end

Running SomeSuite is trivial.

Now how to augment that so if a caller has supplied one case name
(perhaps
via command line arguments and ARGV[]), and then only run that one case?

Suppose I only want to run test_runThisCase. If I had invented
Ruby/Unit, we
could run it like this:

got = runner.run(aTestSuite, ‘test_readMyPost’)

Unfortunately, the test.rb files (like many Ruby library files) are
write-only, and I generally can’t read them well enough to understand
how to
apply that syntax. Is such a feature available through these objects?

Alternately, could I loop thru aTestSuite’s cases, find it, and run it?

(I’m not asking how to run test suites, or how to parse command line
arguments here!)

8

On Sep 4, 2006, at 4:30 PM, Phlip wrote:

name, only run that one case?

if ARGV[0]
system(“ruby tc_#{ARGV[0]}.rb”)
end

9

On Sep 4, 2006, at 9:25 PM, Phlip wrote:

A “test suite” is (generally) a list of test cases. Here, it is a
end
end

Running SomeSuite is trivial.

Now I see your problem.

def test_blah
end

is NOT a test case as far as the established terminology is
concerned. It is a test.

class A < Test::Unit::TestCase
def test_one
end

def test_two
end

def test_three
end

end

is a test case. (hence it’s inheritance from TestCase), a test case
being a collection of tests.

A test suite is a collection of test cases. Usually a test suite is
defined as a single file ts_something.rb containing

require ‘tc_one’
require ‘tc_two’
require ‘tc_etc’

where tc_one.rb, tc_two.rb, etc. each contain one test case. (one
class that inherits from Test::Unit::TestCase). You’re problem was
that you were asking the wrong question. You didn’t want to know how
to run an individual test case, you wanted to know how to run an
individual test. Unfortunately, I do not know how to do that, short
of having one test per test case, and having one test case per file.

10

On 9/5/06, Logan C. [email protected] wrote:

   #...

def test_three

require ‘tc_two’
require ‘tc_etc’

where tc_one.rb, tc_two.rb, etc. each contain one test case. (one
class that inherits from Test::Unit::TestCase). You’re problem was
that you were asking the wrong question. You didn’t want to know how
to run an individual test case, you wanted to know how to run an
individual test. Unfortunately, I do not know how to do that, short
of having one test per test case, and having one test case per file.

Few comments:

  1. You don’t need to create the suite and/or the runner yourself, if
    you want to run all tests in the required files.
    Test::Unit::AutoRunner takes care of it.
    Just ‘require’ all the files with your tests and you are done.

  2. In that case running your main test file (the one that requires the
    others) with ‘–help’ parameter gives you usage help. In your case,
    you are looking for -n or --name where you can pass string or regex to
    filter out your tests by name (-n “test_one” or -n /one/). Another
    would -t that allows you to filter your test case classes.

  3. If you for some reason need to have your own runner, or own
    TestSuite, read the sources. They are indeed very readable. You are
    interested in test/unit/autorunner.rb (@filters),
    test/unit/collector.rb (#add_suite) and
    test/unit/collector/objectspace.rb

11

[One more irritation here - not all messages to Google G. or the
mailing
list get thru to USENET…]

Logan C. wrote:

Now I see your problem.

You have a typo there; one extra ‘y’.

def test_blah
end

is NOT a test case as far as the established terminology is concerned. It
is a test.

I once worked a project where the QA group insisted on saying “we
regressed
the current version today”, when they meant, “We tested the current
version
against regressions today”. Citing the dictionary definition of
“regress”
did not help them change their ways; apparently their industry has a
streak
of mis-use for that term.

http://en.wikipedia.org/wiki/Test_case

“In software engineering, a test case is a set of conditions or
variables
under which a tester will determine if a requirement upon an application
is
partially or fully satisfied.”

Naturally, that’s the definition for manual testing. WikiPedia is free
of
points of view. The overall gist is that one (1) test case represents
the
Assemble Activate Assert cycle of one def test_blah(). An automated test
case, within a version control system, will automatically satisfy each
line-item of their manual test write-up. Note especially the line
“Written
test cases are usually collected into test suites.”

There is a special reason most *Unit rigs call the parent of their
suites
'TestCase’s. They implement the Interpreter Design Pattern, such that
each
Case may instead be a Suite containing many Cases, recursively. So the
top
thing’s a Case, even though we normally derive from it to immediately
create
a Suite. The English connotations are a Case is a single unit and a
Suite is
a group of units.

AutoRunner noted; I will try it after I … calm down. :wink: Thanks all.

12

On Sep 5, 2006, at 1:40 AM, Phlip wrote:

[One more irritation here - not all messages to Google G. or
the mailing
list get thru to USENET…]

Logan C. wrote:

Now I see your problem.

You have a typo there; one extra ‘y’.

Noted :wink:

def test_blah
end

is NOT a test case as far as the established terminology is
concerned. It
is a test.

[snip definitions/story]

AutoRunner noted; I will try it after I … calm down. :wink: Thanks all.

I’m glad you got help for your problem. Sorry there was a clash of
terminology.

13

On Sep 5, 2006, at 12:40 AM, Phlip wrote:

[One more irritation here - not all messages to Google G. or
the mailing
list get thru to USENET…]

The Gateway is struggling a bit. I’m looking into it…

James Edward G. II

14

Hi.

Phlip wrote:

[…] only run that one case?

Do any of these answer your question?

http://groups.google.com/groups?q=test+unit+ruby+one+test

Regards,

15

Bil K. wrote:

Do any of these answer your question?

http://groups.google.com/groups?q=test+unit+ruby+one+test

Thaaanks, Bil!

I always hammer a question with Google before posting. In this case, the
first several answers ass-umed the programmer went with the automatic
AutoRunner, which I didn’t use. This left me reading posts where
AutoRunner
was as hidden and unmentioned as it is in most test suites themselves. I
couldn’t use those posts.

I have since simplified the top-level test.rb, so it can use AutoRunner,
and
now I get the -v and -n that I have since been working around…

I will now research how to run my post-test cleanup code automatically
after
AutoRunner. Or something…

16

On 9/6/06, Phlip [email protected] wrote:

I will now research how to run my post-test cleanup code automatically after
AutoRunner. Or something…

AutoRunner uses at_exit. So think whether your at_exit should be
defined sooner or later that theirs. My tip is that sooner, as they
are run in reverse order IIRC.

J.

17

I will now research how to run my post-test cleanup code automatically
after AutoRunner. Or something…

Just so I don’t leave a false trail in the archives, it’s END {
cleanUp() }
at the top of the first file. Must be the top, else it registers after
whatever runs AutoRunner…