[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: assert

Wood, Jeff

11/17/2004 5:16:00 PM

10 Answers

Florian Gross

11/17/2004 6:31:00 PM

0

Wood, Jeff wrote:

> It's a semantic thing, but you could also go with an #ensure name
> But, I guess I have a question, why not just have a function that
> switches asserts to either raise an exception or cause an IRB
> session? that way you could KNOW your code isn't going to break into
> IRB in it's production environment, unless you specifically ask it
> to...

Problem with using assert() for the method name is that test/unit
already uses it for stating what a test ought to produce. It seems
likely that you will have test/unit style assert()s and breakpoint style
assert()s (which I'd like to call assumptions) in the same code base.

Gavin Sinclair

11/17/2004 10:44:00 PM

0

On Thursday, November 18, 2004, 5:33:15 AM, Florian wrote:

> Wood, Jeff wrote:

>> It's a semantic thing, but you could also go with an #ensure name
>> But, I guess I have a question, why not just have a function that
>> switches asserts to either raise an exception or cause an IRB
>> session? that way you could KNOW your code isn't going to break into
>> IRB in it's production environment, unless you specifically ask it
>> to...

> Problem with using assert() for the method name is that test/unit
> already uses it for stating what a test ought to produce. It seems
> likely that you will have test/unit style assert()s and breakpoint style
> assert()s (which I'd like to call assumptions) in the same code base.

And they are completely different things, so should not be toggled
from one to the other with a global switch. A typical test case will
have dozens or hundreds of asserts, but only one or two breakpoints.
And the breakpoints are very temporary; once you've worked out what's
going on, you remove them.

Testing and debugging are very different.

Gavin



Florian Gross

11/18/2004 12:52:00 AM

0

Gavin Sinclair wrote:

>>Problem with using assert() for the method name is that test/unit
>>already uses it for stating what a test ought to produce. It seems
>>likely that you will have test/unit style assert()s and breakpoint style
>>assert()s (which I'd like to call assumptions) in the same code base.
>
> And they are completely different things, so should not be toggled
> from one to the other with a global switch. A typical test case will
> have dozens or hundreds of asserts, but only one or two breakpoints.
> And the breakpoints are very temporary; once you've worked out what's
> going on, you remove them.
>
> Testing and debugging are very different.

I agree with you here though I think it can still make sense to toggle
between different implementations of assume(). For example it might be a
good idea to log the failed assumption into a warning log file for
production applications and so on.

Gavin Sinclair

11/18/2004 1:41:00 AM

0

On Thursday, November 18, 2004, 11:53:15 AM, Florian wrote:

> Gavin Sinclair wrote:

>>>Problem with using assert() for the method name is that test/unit
>>>already uses it for stating what a test ought to produce. It seems
>>>likely that you will have test/unit style assert()s and breakpoint style
>>>assert()s (which I'd like to call assumptions) in the same code base.
>>
>> And they are completely different things, so should not be toggled
>> from one to the other with a global switch. A typical test case will
>> have dozens or hundreds of asserts, but only one or two breakpoints.
>> And the breakpoints are very temporary; once you've worked out what's
>> going on, you remove them.
>>
>> Testing and debugging are very different.

> I agree with you here though I think it can still make sense to toggle
> between different implementations of assume(). For example it might be a
> good idea to log the failed assumption into a warning log file for
> production applications and so on.

That it can make sense is one thing, but delivering an API that makes
sense is another :) 10 different people would want assume() to do 6
different things in 3 different contexts. Trying to account for all
that seems futile.

Hopefully people can use the available software to do the things they
want to do (if it's logging in production, breakpoints in testing, or
whatever). If they can't, they can suggest improvements.

Gavin



Jean-Hugues ROBERT

11/18/2004 9:59:00 AM

0

At 03:33 18/11/2004 +0900, you wrote:
>Wood, Jeff wrote:
>
>>It's a semantic thing, but you could also go with an #ensure name
>>But, I guess I have a question, why not just have a function that
>>switches asserts to either raise an exception or cause an IRB
>>session? that way you could KNOW your code isn't going to break into
>>IRB in it's production environment, unless you specifically ask it
>>to...
>
>Problem with using assert() for the method name is that test/unit already uses it for stating what a test ought to produce. It seems likely that you will have test/unit style assert()s and breakpoint style assert()s (which I'd like to call assumptions) in the same code base.

I suppose that assert() can still be used. The new
version would I have to figure out that it runs in
the context of test/unit. In that context its behavior
would be compatible with test/unit.

The other contexts that assert() should support are:
- production => throw an exception
- debugging => start an irb session
- custom => invoke some user provided assert failure handler

My 2 Euro cents,

Yours,

JeanHuguesRobert

-------------------------------------------------------------------------
Web: http://hdl.handle.net/1...
Phone: +33 (0) 4 92 27 74 17



Jean-Hugues ROBERT

11/18/2004 10:00:00 AM

0

At 07:44 18/11/2004 +0900, you wrote:
>On Thursday, November 18, 2004, 5:33:15 AM, Florian wrote:
>
>> Wood, Jeff wrote:
>
>>> It's a semantic thing, but you could also go with an #ensure name
>>> But, I guess I have a question, why not just have a function that
>>> switches asserts to either raise an exception or cause an IRB
>>> session? that way you could KNOW your code isn't going to break into
>>> IRB in it's production environment, unless you specifically ask it
>>> to...
>
>> Problem with using assert() for the method name is that test/unit
>> already uses it for stating what a test ought to produce. It seems
>> likely that you will have test/unit style assert()s and breakpoint style
>> assert()s (which I'd like to call assumptions) in the same code base.
>
>And they are completely different things, so should not be toggled
>from one to the other with a global switch. A typical test case will
>have dozens or hundreds of asserts, but only one or two breakpoints.
>And the breakpoints are very temporary; once you've worked out what's
>going on, you remove them.
>
>Testing and debugging are very different.
>
>Gavin

I too don't feel like assert() and breakpoint() are interchangeable.
However, I do feel like assert failure leading to the same effect
as breakpoint() is a good thing, when debugging.

Yours,

JeanHuguesRobert

-------------------------------------------------------------------------
Web: http://hdl.handle.net/1...
Phone: +33 (0) 4 92 27 74 17



Florian Gross

11/18/2004 3:40:00 PM

0

Jean-Hugues ROBERT wrote:

>> Problem with using assert() for the method name is that test/unit
>> already uses it for stating what a test ought to produce. It seems
>> likely that you will have test/unit style assert()s and breakpoint
>> style assert()s (which I'd like to call assumptions) in the same
>> code base.
>
> I suppose that assert() can still be used. The new version would I
> have to figure out that it runs in the context of test/unit. In that
> context its behavior would be compatible with test/unit.
>
> The other contexts that assert() should support are: - production =>
> throw an exception - debugging => start an irb session - custom
> => invoke some user provided assert failure handler

This is an interesting idea. I think I will try it out.

Its Me

11/21/2004 4:44:00 AM

0

> I suppose that assert() can still be used. The new
> version would I have to figure out that it runs in
> the context of test/unit. In that context its behavior
> would be compatible with test/unit.
>
> The other contexts that assert() should support are:
> - production => throw an exception
> - debugging => start an irb session
> - custom => invoke some user provided assert failure handler

I like this the best of all I've seen so far.


Gavin Sinclair

11/21/2004 11:24:00 PM

0

On Sunday, November 21, 2004, 3:48:08 PM, itsme213 wrote:

>> I suppose that assert() can still be used. The new
>> version would I have to figure out that it runs in
>> the context of test/unit. In that context its behavior
>> would be compatible with test/unit.
>>
>> The other contexts that assert() should support are:
>> - production => throw an exception
>> - debugging => start an irb session
>> - custom => invoke some user provided assert failure handler

> I like this the best of all I've seen so far.

This is a good idea to an extent. I doubt how much it would be used
in practice. To me, the use-cases for production and debugging are so
different that the same code can't serve them both.

Anyway, this kind of functionality is the responsibility of an
Assumptions framework. (To avoid clasing with Test::Unit::Assertions.)

require 'assumptions'

Assumptions.configure do |a|
a.in_debug { start_irb }
a.in_production { throw_exception }
a.custom { ... }
end

Assumptions.current_mode = :debug

...

customers.each do |c|
assume c.full_name == [c.first_name, c.last_name].join(' ')
end

What I'm saying is that this functionality can't reasonably be built
into a single method ("assert") and distributed. The above code is,
to my mind, as simple as possible, but no simpler.

Why not create something like this called Assumptions? Then use the
top-level "assume" method everywhere. If it's good, I'll include it
in dev-utils, because it's obviously a good fit. But I have no
interest in creating it myself: it sounds a lot more useful in theory
than in practice.

Cheers,
Gavin



Matt Armstrong

11/22/2004 7:08:00 AM

0

Gavin Sinclair <gsinclair@soyabean.com.au> writes:

> On Sunday, November 21, 2004, 3:48:08 PM, itsme213 wrote:

[...]

>>> The other contexts that assert() should support are:
>>> - production => throw an exception
>>> - debugging => start an irb session
>>> - custom => invoke some user provided assert failure handler
>
>> I like this the best of all I've seen so far.
>
> This is a good idea to an extent. I doubt how much it would be used
> in practice. To me, the use-cases for production and debugging are
> so different that the same code can't serve them both.

[...]

> require 'assumptions'
>
> Assumptions.configure do |a|
> a.in_debug { start_irb }
> a.in_production { throw_exception }
> a.custom { ... }
> end
>
> Assumptions.current_mode = :debug

[...]

> Why not create something like this called Assumptions? Then use the
> top-level "assume" method everywhere. If it's good, I'll include it
> in dev-utils, because it's obviously a good fit. But I have no
> interest in creating it myself: it sounds a lot more useful in
> theory than in practice.

I doubt I would ever use this. If I want production code throwing
exceptions, I will either explicitly code the call to raise with an
appropriate exception class or let the built in class do it (array
bounds, etc.). I wouldn't want generic "assertion failed" exceptions
being thrown.


--
matt