On Thursday 22 January 2004 9:27 am, Michael Roberts wrote:

> setUp
> 	stream _ WriteStream on: ''
>
> tearDown
> 	stream _ nil
>
> testMe
> 	self assert: stream notNil.
> 	stream nextPutAll: 'I have a cunning plan'.
> 	self assert: false
>
> The thing that is confusing me is this:
> 1) the test should fail on the last line.  You can set this to true to
> check it passes.
>
> 2) SUnit brings up a debugger on the failing test but stream is nil so you
> can't get past the first line.  I have started to walk through this code
> and below is my idea so far...
>
> TestCase>>runAsFailure: does a self setUp followed by self
> openDebuggerOnFailingTestMethod which in turn runs the test in its own
> process and attaches the debugger.
>
> 3) When the debugger runs, however, stream is nil as illustrated by the
> position of the debugger highlight and checking the object's state.  I'm
> guessing that somewhere the test execution is stopped at the first error.
> this isn't the line that caused the assertion though.

What's happening is that tearDown is being called before the debugger opens. 
Thus your stream gets nil'd out and you can't test it.

> runCaseAsFailure: aSemaphore
> 	[self setUp.
> 	self openDebuggerOnFailingTestMethod] sunitEnsure: [
> 		self tearDown.
> 		aSemaphore signal]
>
> which should be the same place that opened the debugger earlier.
>
> 7) how does the block to sunitEnsure: wait for
> openDebuggerOnFailingTestMethod to finish?  It should just be a normal
> block being sent >>value.

Ah, but it doesn't finish. Instead the assert raises an exception, which kicks 
the tearDown method.

See if it works the way you want if you take out the assignment to stream in 
your tearDown method.

My own feeling on this is that probably the tearDown should be moved inside 
the openDebugger... method along with performTest so you can see your context 
better and you won't get tearDown called when an exception is raised.