Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > assert_equal hates my CPU

Reply
Thread Tools

assert_equal hates my CPU

 
 
Phlip
Guest
Posts: n/a
 
      04-14-2005
Rubies:

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.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces


 
Reply With Quote
 
 
 
 
Saynatkari
Guest
Posts: n/a
 
      04-14-2005

Le 14/4/2005, "Phlip" <(E-Mail Removed)> a écrit:
>Rubies:
>
>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

--
No-one expects the Solaris POSIX implementation!



 
Reply With Quote
 
 
 
 
Francis Hwang
Guest
Posts: n/a
 
      04-14-2005

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.


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
http://fhwang.net/



 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      04-14-2005
Saynatkari wrote:

> test/unit has a built-in load tester


Do you mean the profiler?

Otherwise, where do I Google?

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

> No-one expects the Solaris POSIX implementation!


Whip me. Beat me. Make me install Oracle.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces


 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      04-14-2005
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 ...


How long do your tests take?

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces


 
Reply With Quote
 
Michael Walter
Guest
Posts: n/a
 
      04-14-2005
Phlip,

On 4/13/05, Phlip <(E-Mail Removed)> wrote:
> 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?

Regards,
Michael



 
Reply With Quote
 
Francis Hwang
Guest
Posts: n/a
 
      04-14-2005
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 ...

>
> How long do your tests take?
>
> --
> Phlip
>
> http://industrialxp.org/community/bin/view/Main/
> TestFirstUserInterfaces
>
>
>
>


Francis Hwang
http://fhwang.net/



 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      04-14-2005
Michael Walter wrote:

> That's too much magic in the block semantics for me.


I think my question is visible beyond the minor typos.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces



 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      04-14-2005
Francis Hwang wrote:

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

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces



 
Reply With Quote
 
Michael Walter
Guest
Posts: n/a
 
      04-14-2005
Phlip,

On 4/14/05, Phlip <(E-Mail Removed)> wrote:
> Michael Walter wrote:
>
> > That's too much magic in the block semantics for me.

>
> I think my question is visible beyond the minor typos.


The comment (as detailed in the remainder you snipped) is not about typos.

Regards,
Michael



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
assert_equal problem Ranieri Teixeira Ruby 3 02-04-2008 10:16 PM
Unit Testing, how to use assert_equal for last printed line? Feng Tien Ruby 4 10-24-2007 04:24 PM
My CPU Hates Me Ari Brown Ruby 4 07-07-2007 02:12 AM
I'm not the only one who hates the MCNGP lowdes MCSE 59 09-13-2005 05:39 PM
My Computer hates Nero Fitzy_bhoy Computer Support 11 05-13-2004 03:03 AM



Advertisments