I just realized that it is a common idiom to put a TestCase in a single file, but this convention could be made easier to use.
IMO it would be nice to have
require 'test/unit'
def test_foo
end
instead of
require test/unit
class TC_FooBar < Test::Unit::TestCase
def test_foo
..
end
end
not a big deal, I know
I think it should be easy to do this, by mixing the code from the file in a custom object, or building a whole new TestCase subclass dynamically. #setup and #teardown methods should still work fine, I think. The name for the TestCase could be taken from the filename, becoming a little more DRYish.
This is a departure from the xUnit heritage, but I think that taking advantage of ruby's features and make Test::Unit simpler to use by "evolving" it a little bit was already planned. Is this a bad idea?
I've gotten tired of this verbosity myself and have started playing
with:
require 'quicktest'
test :foo {
...
}
Truly amazing, I wrote *exactly* the same thing for myself. Except
mine is called "quiktest" and the test name is optional (you need to
use parens or do...end in above, btw).
I've gotten tired of this verbosity myself and have started playing
with:
require 'quicktest'
test :foo {
...
}
Truly amazing, I wrote *exactly* the same thing for myself. Except
mine is called "quiktest" and the test name is optional (you need to
use parens or do...end in above, btw).
quicktest seem to be a common name[1]
IIRC something like this was already planned from Nathaniel Talbott, but I think that if you're writing a single test class per file even the test{} could be avoided.
[1] I wrote a "quicktest" thing too, but it was different, wrapping sparse assertions in a test case to allow testing quick scripts like this:
def foo(x,y)
..
end
assert_equal something, foo(2,3)
Truly amazing, I wrote *exactly* the same thing for myself. Except
mine is called "quiktest" and the test name is optional (you need to
use parens or do...end in above, btw).
Thanks for this, I had been "playing" and hadn't yet coded it. So yours
came in very handy :-). It has two bugs though. 1) The #to_s on name
must go. And 2) using the -d option causes Test::Unit to alos dump it's
debug info too. Not good (It'd be nice if we had some sort of debug
level system, perhaps based on module nesting levels.)
I've gotten tired of this verbosity myself and have started playing
with:
require 'quicktest'
test :foo {
...
}
Truly amazing, I wrote *exactly* the same thing for myself. Except
mine is called "quiktest" and the test name is optional (you need to
use parens or do...end in above, btw).
quicktest seem to be a common name[1]
IIRC something like this was already planned from Nathaniel Talbott,
but I think that if you're writing a single test class per file even
the test{} could be avoided.
quiktest was primarily made to add the tests in the same file as the
library (they only get run with ruby -d).
[1] I wrote a "quicktest" thing too, but it was different, wrapping
sparse assertions in a test case to allow testing quick scripts like
this:
def foo(x,y)
..
end
assert_equal something, foo(2,3)
Wrapping them with test{} doesn't hurt and you can reuse the file.
Another idea is to do something like:
Truly amazing, I wrote *exactly* the same thing for myself. Except
mine is called "quiktest" and the test name is optional (you need to
use parens or do...end in above, btw).
Thanks for this, I had been "playing" and hadn't yet coded it. So yours
came in very handy :-). It has two bugs though. 1) The #to_s on name
must go. And 2) using the -d option causes Test::Unit to alos dump it's
debug info too. Not good (It'd be nice if we had some sort of debug
level system, perhaps based on module nesting levels.)
You're right, the code doesn't work at all. It was just a quick
hack, and I must have kept the wrong version.
Feel free to take it, however, and make something useful.
[1] I wrote a "quicktest" thing too, but it was different, wrapping
sparse assertions in a test case to allow testing quick scripts like
this:
def foo(x,y)
..
end
assert_equal something, foo(2,3)
Wrapping them with test{} doesn't hurt and you can reuse the file.
sure, the reason I wrote this was to *quickly* test scripts, i.e. when answering messages in ruby-talk on how to do something. I would'nt advocate this to be actually used for anything
