Here's the Ruby 1.8 test\unit version of assert_equal()
def assert_equal(expected, actual, message=nil)
full_message = build_message(message, <<EOT, expected, actual)
<?> expected but was
<?>.
EOT
assert_block(full_message) { expected == actual }
end
Notice it builds a message even if the assertion passes.
Because assertions passing should be the most common behavior, shouldn't
that method run like this?
def assert_equal(expected, actual, message=nil)
assert_block(full_message) do
if expected == actual then
''
else
build_message(message, <<EOT, expected, actual)
<?> expected but was
<?>.
EOT
end
end
end
Then assert_block() should trigger if its block yields a complaint string.
Here's the Ruby 1.8 test\unit version of assert_equal()
def assert_equal(expected, actual, message=nil)
full_message = build_message(message, <<EOT, expected, actual)
<?> expected but was
<?>.
EOT
assert_block(full_message) { expected == actual }
end
Notice it builds a message even if the assertion passes.
Because assertions passing should be the most common behavior, shouldn't
that method run like this?
def assert_equal(expected, actual, message=nil)
assert_block(full_message) do
if expected == actual then
''
else
build_message(message, <<EOT, expected, actual)
<?> expected but was
<?>.
EOT
end
end
end
Then assert_block() should trigger if its block yields a complaint string.
test/unit has a built-in load tester
Yes, it would make more sense the other way but
I suspect this is due to simpler implementation
and the idea that assertions do not run in production
code so it does not matter. I can not test it
right now but it does not seem like your code
would actually run since 'full_message' does
not exist?
Phlip
E
···
Le 14/4/2005, "Phlip" <phlip_cpp@yahoo.com> a écrit:
--
No-one expects the Solaris POSIX implementation!
Because assertions passing should be the most common behavior, shouldn't
that method run like this?
def assert_equal(expected, actual, message=nil)
assert_block(full_message) do
if expected == actual then
''
else
build_message(message, <<EOT, expected, actual)
<?> expected but was
<?>.
EOT
end
end
end
Unbound variable 'full_message'? :\
Then assert_block() should trigger if its block yields a complaint string.
That's too much magic in the block semantics for me. Without taking a
look into the test sources, mayb you could call some
raise_error(reason) function instead?
Ah, but it can matter, can't it? If you're running a codebase with, say, 500+ unit tests and 1900+ assertions (hell, I'm running one right now), these things can add up. And when your tests are slow, you'll run them less often ...
Francis Hwang
···
On Apr 13, 2005, at 11:21 PM, Saynatkari wrote:
I suspect this is due to simpler implementation
and the idea that assertions do not run in production
code so it does not matter.
Yes, it would make more sense the other way but
I suspect this is due to simpler implementation
and the idea that assertions do not run in production
code so it does not matter. I can not test it
right now but it does not seem like your code
would actually run since 'full_message' does
not exist?
I want my tests to run in <5 seconds. Otherwise I get bored, drift off,
start downloading comics, etc.
Ah, but it can matter, can't it? If you're running a codebase with,
say, 500+ unit tests and 1900+ assertions (hell, I'm running one right
now), these things can add up. And when your tests are slow, you'll run
them less often ...
Yes, it would make more sense the other way but
I suspect this is due to simpler implementation
and the idea that assertions do not run in production
code so it does not matter. I can not test it
right now but it does not seem like your code
would actually run since 'full_message' does
not exist?
I want my tests to run in <5 seconds. Otherwise I get bored, drift off,
start downloading comics, etc.
120 seconds, give or take, when I run the whole suite. This is one of the reasons I'm always looking for chunks of code to extract into their own libs; you decrease cohesion, and accordingly you decrease the combinatorial space your tests have to deal with.
···
On Apr 13, 2005, at 11:59 PM, Phlip wrote:
Francis Hwang wrote:
Ah, but it can matter, can't it? If you're running a codebase with,
say, 500+ unit tests and 1900+ assertions (hell, I'm running one right
now), these things can add up. And when your tests are slow, you'll run
them less often ...
It depends on what I'm working on. If I want to check in:
$ time make
ruby -w -I.:../../ParseTree/dev/lib:../../ParseTree/dev/test test_all.rb
Loaded suite test_all
Started
....................................................................................................................................................................................................................................................................................................................................................................
Finished in 4.749234 seconds.
356 tests, 714 assertions, 0 failures, 0 errors
real 0m5.916s
user 0m4.400s
sys 0m0.150s
If I'm working on just one thing:
$ time ruby -w -I.:../../ParseTree/dev/lib:../../ParseTree/dev/test test_all.rb -n /test_iteration/
Loaded suite test_all
Started
........................
Finished in 0.448557 seconds.
Ah, but it can matter, can't it? If you're running a codebase with,
say, 500+ unit tests and 1900+ assertions (hell, I'm running one right
now), these things can add up. And when your tests are slow, you'll run
them less often ...
120 seconds, give or take, when I run the whole suite. This is one of
the reasons I'm always looking for chunks of code to extract into their
own libs; you decrease cohesion, and accordingly you decrease the
combinatorial space your tests have to deal with.
Ah, I'm looking at a much lower ratio of cases to seconds. So profiling and
optimizing is now more important than incremental testing.
