Help with SUnit

Michael Roberts mike at mjr104.co.uk
Thu Jan 22 20:54:04 UTC 2004


Hi John,

On Thu, Jan 22, 2004 at 10:20:02AM -0800, John M McIntosh wrote:
> When I attempt this with a 3.7a image and at change set 5566  

ok I'm in 3.7a 5657

>I first  
> use the open menu to open a Test Runner 'SUnit Camp Smalltalk 3.1 Test  
> runner; 

ahh..hmm.. I'm just in SUnit Test Runner.  I haven't done any thing clever and unload anything from the image and reload stuff from SM.  I've just got the one that comes in 3.7.  I'm not sure which version it is but I think it has Ned's enhancements.

>which shows my JMMTestCase, which I select, then I click on the  
> RUN button I get my JMMTestCase failed, I click on the failing method,  

ok I have MikeIsConfusedTest so I hit 'run one'

ok 1 run, 1 failed 

click on the item in the list

> I get a notifier up that when I debug I see
> 

well I don't get the notifier.  I'm straight into the debugger

--- The full stack ---
MikeIsConfusedTest>>testMe
MikeIsConfusedTest(TestCase)>>performTest
[] in MikeIsConfusedTest(TestCase)>>openDebuggerOnFailingTestMethod {[self performTest]}
[] in BlockContext>>newProcess {[self value.  Processor terminateActive]}


> openDebuggerOnFailingTestMethod
> 	"SUnit has halted one step in front of the failing test method. Step  
> over the 'self halt' and
> 	 send into 'self perform: testSelector' to see the failure from the  
> beginning"

well, my version

woah! what's happened to the versions..

The version you describe is the first one, with no method stamp.
and then the next one, nk 8/6/2003, is totally different.

I'm not going mad, I do remember this original method.  I'm not saying there is anything wrong with this new method of course.  This came in with changeset 5593-TestRunnerEnh-nk.  


'Made debugger step to beginning of failed test case.'
Maybe I need to understand what this change did?

Well there have been loads of changes since then.  So I assume that people are happy with the way that SUnit works.

> I'm not sure which image or SUnit version you are using, you might want  
> to try with 3.7a and see what happens since I was unable to reproduce  
> your results.
Yes I should have said which versions I was using.  I try and always use a fresh and latest image for these kind of postings.

I don't wish to sound rude, but would you mind trying my test with the latest version of everything since I think I have the latest version and I'm not sure you do :-)


> 
> Also if I might comment on your
> > tearDown
> > 	stream _ nil
> which technically performs the destruction of the WriteStream instance.  
Thanks for the comments, I appreciate that I opened myself up for that :-) I like to think I'm from a Python background but alas C++ has scared me considerably.  Setting the reference to nil is unnecessary but I did it because I wanted some kind of understanding of what was happening to the fixture.  It would have been better to use strings or print out to the transcript or something like that.

> Explicit deletion can led to bugs, however I'll temper that with the  
> comment that some objects might need closure if they don't have Weak  
> Reference support to ensure system resources are surrendered at GC  
> time, or if the frameworks involved don't forget about them  
> automatically at some point.
> 
> In this case the stream _ nil isn't needed. However if it was a file  
> based stream then a close should be done, mind you weak reference  
> support would ensure the file is closed automatically when the stream  
> was actually GCed even if you didn't do an explicit close.

This leads onto another question that I have about sockets, ConnectionQueue and finalisation.  I'll ask that in another thread.  So many questions.... :-)

> 
> > self halt in tearDown (feeling on dodgy ground now)
> 
> Please feel free to do that anywhere, why else would Smalltalkers ship  
> all the source other than so you can read/learn/fiddle, older  
> smalltalkers might recall (with distaste) when Digitalk and IBM hid  
> source code from us. Mind sticking a self halt anywhere can lead to  
> disaster, but it's a learning experience.
>
I was feeling on dodgy ground because I got stuck in early 3.7 when I couldn't debug things.  I don't really understand code simulation errors.  I love the fact that I can read the source code for the debugger but wonder how I could step through it in another debugger to understand it.

Well, I've bombed out Morphic to an emergency debugger on more than one occasion putting in self halt in the wrong place.  I may go back to that sometime because at the time I wanted the system to be able to cope with my reckless enthusiasm :-)  Missing off super initialise in a morph had similar consequences IIRC.

Well thanks for all the help, I hope for some more kind words soon.

Cheers

Mike



More information about the Squeak-dev mailing list