[wingide-users] global setUp script for unit testing? (and other unittest features)

Warren, Russell russell.warren at newport.com
Mon Feb 25 16:21:46 MST 2008


> One thing I do find, though, is I find myself aborting tests a fair
> amount when I debug them so it may be worthwhile to think of a way
> to work without a tearDown method.

Agreed.  My Wing'ified setUp routines launch the server on a daemonic
thread for this exact reason (when I terminate, the server goes poof,
too).  This prevents me from attaching to a separately running server,
though.  Among other things, my standalone test script has flags to
either attach to a running server or generate the server on a thread.
In the latter case it first detects if one is already running and takes
it down before starting a new one.

This brings up another deficiency I'm left with.  I can't see any way
with my hack implementation to get Wing to allow me to fiddle with
configuration switches on my test suite (short of having it read them
from a config file).  So... when you do add the ability to assign global
setUp and tearDown scripts, please be sure to remember to add the
ability to add runtime arguments on each.

In short... thanks again for responding, and I look forward to the
upcoming improvements!

Cheers,
Russ


-----Original Message-----
From: Wingware Support [mailto:support at wingware.com] 
Sent: Monday, February 25, 2008 5:31 PM
To: Warren, Russell
Cc: wingide-users at wingware.com
Subject: Re: [wingide-users] global setUp script for unit testing? (and
other unittest features)

Warren, Russell wrote:
> Yes, this is what I kluged together in the other mail for setUps, but 
> I don't know how to do handle a global tearDown.  Executing something 
> only on the very first setUp is easy... executing something only on 
> the very last tearDown is trickier. How the heck do I know which is
the last one?
> I'd rather not hack into your test runner script if I can avoid it.  
> Got any ideas?

Yes, the global tearDown is the hard part with no easy solution that I
can think of.  I don't think there's any easy way to determine which is
the final test.  One thing I do find, though, is I find myself aborting
tests a fair amount when I debug them so it may be worthwhile to think
of a way to work without a tearDown method.

>> would you want the tests collapsed if they were previously expanded?
> 
> I would be happy with this combo:
> - an "auto-expand failures" global setting as you suggest
> - otherwise preserving the expansion state as you suggest
> - providing an "Expand All" context menu to the test pane
> - providing a  "Collapse All" context menu to the test pane
> - providing an "Expand failures" context menu on test groups
> - providing an "Expand all failures" context menu in the test pane

Seems like a good idea.

> Maybe I didn't experiment enough?  I did read the docs, though.  What 
> I do without Wing is that I have a script with a "GenerateTests" 
> function in it that dynamically generates and returns a TestSuite 
> object.  Then I run unittest.main(defaultTest="GenerateTests") to get 
> the them all to run.  How would I get Wing to recognize the script?  
> Do I just put the TestSuite instance in the global namespace?  I must 
> confess that I didn't try that, but will as soon as I can (can't on
this pc).

Yes, it should work to put them in the global namespace.

Thanks,

John


More information about the wingide-users mailing list