Testing OnceHalter

OnceHalter is an object that halt for once but ignores from then.
It has a boolean instance variable inside that is turned true when it
is firstly halted.



testOnceHalter

        | halter haltedOnce |
        haltedOnce := false.
        halter := OnceHalter new.
        [ halter halt ] on: Signal do: [:e| haltedOnce := true ]. "PROBLEM:
can't avoid halting while the test run"
        halter halt. "no effect"
        self assert: haltedOnce

My PROBLEM is that  trapping the first halt seems hard.
Is it possible?

Best Regards

Howard,

Check the archives for a class called (IIRC) Once.  It is slightly more
generic than what you are trying to do, but will do the job.  Let me
know if you can't find it and I will get it from my image (not readily
available at the moment).  It is _very_ useful for GUI debugging, etc.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Howard,

For things like this (e.g. OS related services or closed 3rd party
libraries) I separate out the logic of the usage of the service from
the actual service itself.

Typically you end up with some policy object that does the actual
service that is hard to test - and you keep it as lean as possible and
just code QA it (in your case, an object that does "self halt" is not
something you are likely to get wrong). Everything else you put in your
OnceHalter.

I'm a Mock man (see: http://www.macta.f2s.com/Thoughts/smock.html) so
my test would look a bit like follows.


halter := OnceHalter with: mockHaltPolicy.

self mockery exactly: 1 like: [ mockHaltPolicy execute ].

halter halt.
halter halt.  "this one will fail with a too many calls error if my
logic is wrong"


(If you don't want to have a real HaltPolicy object , you could use a
block and change the above to: ....like: [ mockHaltPolicy value] and
just pass in a block to implement halt).

Bill, I found it.

"Once" object by Inspiring Chris at year 2004.
http://groups.google.co.kr/group/comp.lang.smalltalk.dolphin/browse_thread/thread/6f193374a8b62f39/6af236bdc7e4ba37?q=Once&rnum=1#6af236bdc7e4ba37

I will drop my OnceHalter and use Once which has been verified for 2
years in this community. It is more generic as you've mentioned.

Thanks

I'm not very familiar with MockObjects. I've heard of them but never
used them nor tried to implement them.
Your page may give me a chance to learn about them.

PS: how do you test Mocks?

Howard,

> "Once" object by Chris at year 2004.

Dear me, I'd forgotten all about that !

    -- chris

>How do you test Mocks

Well - the library itself is frustratingly tested in a long handed way
(e.g. I don't test itself in itself as that gets too confusing). In
many cases I test leaf objects with #should:raise:, I also create some
stub objects with counters to see if things were called correctly.

Those tests paid off however, as I made some radical changes to the
library along the way - and more often than not some test flagged a
mistake I had made.

However once you can use the library, life is much easier (in my
opinion) as you are testing the relationships between objects (and the
parameters of those relationships) rather than testing the final state
of objects (e.g. trying to get state out of them to see if its right).

Also - given the dynamic nature of smalltalk you don't actually have to
write any code to implement a mock, you just instantiate one and
configure it. This said - you may want a final "end to end" test to
make sure you have stitched everything together properly (e.g. think
Fit or Selenium or Sahi) - but I find the mock approach helps me
separate things up nicely and I make less mistakes that way.

I have also been experimenting with using the TDD aspect of mocks to
generate code for the things you have mocked out (and hence discovered
the interface for). It looks promising.

Tim