pyunit-interest

[Pyunit-interest] how do i use an unsigned int

[Yvan C. <Yv...@va...>]

I am calling a C-function that returns an unsigned int
Python, though, allocate a integer (so i get the wrong value (negative
number))

How would i force Python to allocate a unsigned int?

Yvan

PS: Thanks for all the previous answers, you guys are helping me a lot

Re: [Pyunit-interest] setting the current directory

[Steve P. <ste...@ya...>]

Yvan Charpentier wrote:
> Does anybody know how to set the current directory
> 
> For example, if curdir is c:\Python-2.0 and i want it to be D:\TEST
> 
> i tried 
> 
> import os
> os.curdir  = 'D:\\TEST'
> 
> but it did not change the current directory

Try os.chdir()

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/

Re: [Pyunit-interest] newby in Python

[Steve P. <ste...@ya...>]

Or, even more simply, put as many unittest.TestCase subclasses as
you like in one file, giving any test methods the prefix 'test', and
the following will magically run all the tests when the file is executed:

   import unittest

   class SimpleTestCase(unittest.TestCase):

      def test_a_number(self):
         number = 0
         assert number == 1

      def test_another_number(self):
         number = 1
         assert number == 1

   if __name__ == '__main__':
      unittest.main()

The following output is produced when the file is run from the command
line:

   F.
   ======================================================================
   FAIL: test_a_number (__main__.SimpleTestCase)
   ----------------------------------------------------------------------
   Traceback (innermost last):
     File "test.py", line 7, in test_a_number
       assert number == 1
   AssertionError: 
   
   ----------------------------------------------------------------------
   Ran 2 tests in 0.001s
   
   FAILED (failures=1)


-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/

[Pyunit-interest] setting the current directory

[Yvan C. <Yv...@va...>]

Does anybody know how to set the current directory

For example, if curdir is c:\Python-2.0 and i want it to be D:\TEST

i tried 

import os
os.curdir  = 'D:\\TEST'

but it did not change the current directory

Thanks a lot

Yvan

Re: [Pyunit-interest] newby in Python

[robin a. j. <rob...@ea...>]

OK Yvan,

This is jim responding from a different e-mail account than the previous
message.

Here is one way to do unit testing using the unittest module:

class SteamTestCase(unittest.TestCase):

   def check_Test_1(self):
      print """Test 1 openfile"""
      number = 0
      assert number == 1

   def check_Test_2(self):
      print """Test 2 openfile"""
      number = 0
      assert number == 1

   # add as many test methods for the SteamTestCase class as desired here



# add as many test classes (each with test methods) here as desired


def suite ():
   """ Returns a suite containing all the test cases in this module. """

   test_suite_classes = [SteamTestCase] # add as many classes here as
defined above

   test_suites = [ ] # empty list

   for item in test_suite_classes:
      test_suites.append ( unittest.makeSuite (item, 'check_') )

   return unittest.TestSuite (test_suites)



import sys
test_runner = unittest.TextTestRunner(sys.stdout, verbosity=2)
test_runner.run(suite())



And here is the output from the above:

check_Test_1 (__main__.SteamTestCase) ... Test 1 openfile
FAIL
check_Test_2 (__main__.SteamTestCase) ... Test 2 openfile
FAIL

======================================================================
FAIL: check_Test_1 (__main__.SteamTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "temp.py", line 8, in check_Test_1
    assert number == 1
AssertionError
======================================================================
FAIL: check_Test_2 (__main__.SteamTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "temp.py", line 13, in check_Test_2
    assert number == 1
AssertionError
----------------------------------------------------------------------
Ran 2 tests in 0.060s

FAILED (failures=2)


----- Original Message -----
From: "Yvan Charpentier" <Yv...@va...>
To: <pyu...@li...>
Sent: Wednesday, October 31, 2001 2:41 PM
Subject: [Pyunit-interest] newby in Python


> Hi everybody,
>
> I am pretyy new using python and the unittest framework. I am trying
> implement the easiest test, see code below:
>
> #! /usr/local/bin/python
>
> print "Running test.py"
> import unittest
>
> class SteamTestCase(unittest.TestCase):
> def runTest(self):
> print """Test openfile"""
> number = 0
> assert number == 1
>
> TestOpenFile = SteamTestCase()
> print TestOpenFile
>
>
> print """End of test"""
>
> For some reasons, it seems that the code in the runTest in not executed. I
> am not seing any assert or print in that function
> print TestOpenFile returns runTest (__main__.SteamTestCase), though
>
> Is there something obvious i am missing?
> Thank you
>
> Yvan
>
>
>
>
>
>
>
>
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyunit-interest

[Pyunit-interest] newby in Python

[Yvan C. <Yv...@va...>]

Hi everybody,

I am pretyy new using python and the unittest framework. I am trying
implement the easiest test, see code below:

#! /usr/local/bin/python

print "Running test.py"
import unittest

class SteamTestCase(unittest.TestCase):
	def runTest(self):
		print """Test openfile"""
		number = 0
		assert number == 1
	
TestOpenFile = SteamTestCase()
print TestOpenFile


print """End of test"""

For some reasons, it seems that the code in the runTest in not executed. I
am not seing any assert or print in that function
print TestOpenFile returns runTest (__main__.SteamTestCase), though

Is there something obvious i am missing?
Thank you

Yvan

Re: [Pyunit-interest] Unitesting organisation

[Ype K. <yk...@xs...>]

Joel,

>You are right for the testing method.
>
>I think I need to write an other configParser because, url are specify in
>it.  These url are used by some other script download web page.
>I think to use an other configParser with url pointing to a local web site
>on my machine to provide test page.
>
>What do you think about that phylosophy ?

You might split your configParser into a client part and a
parsing part and test the two separately.
The client should obtain data from the right URL, and the  parser should
parse some data correctly.

Once both parts are tested you can test them together: the configParser
output should be the expected output for a (test) URL.

Regards,
Ype

P.S. This might be getting off topic for Pyunit. Reply to me directly
in case you agree.

Re: [Pyunit-interest] Unitesting organisation

[Joel Q. <joe...@ho...>]

You are right for the testing method.

I think I need to write an other configParser because, url are specify in
it.  These url are used by some other script download web page.
I think to use an other configParser with url pointing to a local web site
on my machine to provide test page.

What do you think about that phylosophy ?

Joel
----- Original Message -----
From: "Ype Kingma" <yk...@xs...>
To: "Joel Quinet" <joe...@ho...>
Sent: Saturday, October 27, 2001 10:42 AM
Subject: Re: [Pyunit-interest] Unitesting organisation


Joel,

>Hi all,
>
>I am new to unitTesting practice, I start using it after having red some
>article on
>Extreme Programming.  I have start to implement it in an application I am
>currently
>writing.  I need to do that to be able to improve it quicker, avoid
spending
>time in
>debugging due to change.  I ask myself many question about that.
>
>I have an application in Python to download web pages and extract some data
>from them.
>
>At starting point, I have used a configfile with the configParser Python
>object.
>Due to many value are not changing frequently (principaly url), I have put
>those
>variable directly in the Python code.  Now, I have the following solution,
a
>configfile
>and an object (which use the configParser object to parse the file)
>containing  more
>constant variable in it.  I have also implemented the singleton pattern in
>this object,
>this permit to avoid the parsing of the config file every time.
>
>I have implemented the folowing stuff:
>- I have put my test file in the same folder as the code file.
>- I use the httpServer in python to have a web server for testing
>
>My interrogation are :
>- should I implement a testing configfile and a testing parser object which
>contains variable too ?

That depends on what you want to test.
In case you want to test that your code is using the right
configuration you will need a separate testing configuration to compare to.

However, there is no point in writing another configuration parser.
You can test your configuration parser by feeding it a known configuration
and
compare it's output to some expected parsed configuration data.

> - What is the best solution to avoid name file conflict ?

Use a naming convention for your files. Eg. for testing cfg.py you can use
cfgtests.py, that is systematically add a 'tests' suffix to the name.
You can also put the test files in a separate directory.
Such measures will allow you to collect many unittests lateron easily
into a longer regression test.

>- Should I implement other way to put my testfile ?

I'm not sure what you mean here, but I may have answered this question
already.

>This is my current question.  I hope to be clear enough (English is not my
>mother language).

Pas de problème.

Have fun,
Ype

[Pyunit-interest] Unitesting organisation

[Joel Q. <joe...@ho...>]

Hi all,

I am new to unitTesting practice, I start using it after having red some
article on
Extreme Programming.  I have start to implement it in an application I am
currently
writing.  I need to do that to be able to improve it quicker, avoid spending
time in
debugging due to change.  I ask myself many question about that.

I have an application in Python to download web pages and extract some data
from them.

At starting point, I have used a configfile with the configParser Python
object.
Due to many value are not changing frequently (principaly url), I have put
those
variable directly in the Python code.  Now, I have the following solution, a
configfile
and an object (which use the configParser object to parse the file)
containing  more
constant variable in it.  I have also implemented the singleton pattern in
this object,
this permit to avoid the parsing of the config file every time.

I have implemented the folowing stuff:
- I have put my test file in the same folder as the code file.
- I use the httpServer in python to have a web server for testing

My interrogation are :
- should I implement a testing configfile and a testing parser object which
contains variable too ?
 - What is the best solution to avoid name file conflict ?
- Should I implement other way to put my testfile ?

This is my current question.  I hope to be clear enough (English is not my
mother language).

Thanks for your remarks, questions, and suggestions.

Joel

Re: [Pyunit-interest] PyUnit Only or Unit test ?

[Steve P. <ste...@ya...>]

Joel Quinet wrote:
> Is this mail, only devoted to PyUnit packages or can we also discuss about
> unit testing in python more generaly ?

You're welcome to discuss anything related to testing Python code.

I can't promise to reply personally because I'm snowed under with other
work recently, but there are plenty of wise folk on this list who may be
able to answer your questions.

Best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/

[Pyunit-interest] PyUnit Only or Unit test ?

[Joel Q. <joe...@ho...>]

Hi all,

Is this mail, only devoted to PyUnit packages or can we also discuss about
unit testing in python more generaly ?
Like asking "How to make unit testing for a singleton object pattern" ?

Joel

[Pyunit-interest] run setUp once for a suite

[Mark M. <ma...@mc...>]

Suppose I wanted to setUp a fixture once for a suite of tests.  For example,
creating a test database before running all tests and dropping it only after
all tests were complete.

How would I do that?

I know that I can setUp a fixture for each test (as below), but
creating/dropping a database for each test seems like overkill.

class Tests(unittest.TestCase):

	def setUp(self):
		print "setup"

	def test1(self):
		print "test1"

	def test2(self):
		print "test2"

Thanks,

// mark

Re: [Pyunit-interest] setup/teardown for a TestSuite

[Steve P. <ste...@ya...>]

Hi Ype,

Previous discussion on this list of this topic may be hidden behind obscure
subject lines; you're not the first to suggest a setUp and tearDown for
TestSuite.

However, this defeats one of the central ideas of the framework, which is
that each test should be able to run either in isolation or in arbitrary
combination with other tests. That is, each test case should provide for the
setting up and tidying up of the environment in which it runs.

Test cases need not even run as part of a suite:

   class MyTestCase(unittest.TestCase):
       def testSomething(self): pass

   unittest.TextTestRunner().run(MyTestCase())

If the system must be placed into some state before a number of tests are
run, and if that state is certain to be unaffected by the tests, there are
a couple of strategies.

Firstly, each test case could be given a 'setUp' method that lazily sets up
that state, possibly using a helper module.

Secondly, the environment could be set up before the TestRunner is invoked
(or 'unittest.main()' called).

It's worth going to some trouble to make each TestCase outwardly independent
of other code.

Best wishes,

-Steve




Ype Kingma wrote:
> Hello pyunit'ers,
> 
> I recently started using unittest.py, and it serves me well.
> At some point I needed to setUp and tearDown a TestSuite.
> The pattern is:
> - bring a system into an interesting state,
> - perform some testcases on the system,
> - bring the system back into it's original state.
> This is useful when setup and/or teardown
> are non trivial and there are more than a few testcases.
> 
> I checked the archives a bit but there did not seem to be
> any discussion on this.
> 
> So I subclassed SetUpTestSuite from TestSuite. I added methods
> setUpSuite() and tearDownSuite(), called these from the
> __call__() method and allowed for exceptions during setup/teardown
> being reported as test errors.
> 
> Having written the code I realised I could have done it by
> implementing a TestCase to execute a TestSuite.
> 
> Another look at the code made me realise that it might be added
> into TestSuite without introducing too many backward incompatibilities,
> after all I guess that TestSuite isn't subclassed very often.
> 
> The working code is below, comments invited, please use it
> as you see fit.
> 
> Ype


--
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
GPG fingerprint: EB79 2AB1 D494 16F9 8C3B  DAC6 5341 30CE BCCA EBEA

[Pyunit-interest] setup/teardown for a TestSuite

[Ype K. <yk...@xs...>]

Hello pyunit'ers,

I recently started using unittest.py, and it serves me well.
At some point I needed to setUp and tearDown a TestSuite.
The pattern is:
- bring a system into an interesting state,
- perform some testcases on the system,
- bring the system back into it's original state.
This is useful when setup and/or teardown
are non trivial and there are more than a few testcases.

I checked the archives a bit but there did not seem to be
any discussion on this.

So I subclassed SetUpTestSuite from TestSuite. I added methods
setUpSuite() and tearDownSuite(), called these from the
__call__() method and allowed for exceptions during setup/teardown
being reported as test errors.

Having written the code I realised I could have done it by
implementing a TestCase to execute a TestSuite.

Another look at the code made me realise that it might be added
into TestSuite without introducing too many backward incompatibilities,
after all I guess that TestSuite isn't subclassed very often.

The working code is below, comments invited, please use it
as you see fit.

Ype



from unittest import * 
""" To avoid frowned eyebrows you might use (untested):
from unittest import TestSuite, defaultTestLoader
"""

class SetUpTestSuite(TestSuite):
    """ A TestSuite with setUpSuite() and tearDownSuite() methods.
    Exceptions thrown by these methods are reported in the test results.
    """

    def setUpSuite(self): pass # to be overriden
    def tearDownSuite(self): pass # to be overriden

    def __call__(self, result): # with inspiration from TestCase.__call__
        try:
            self.setUpSuite()
        except:
            result.addError(self, self.__exc_info())
            return result
        result = TestSuite.__call__(self, result)
        try:
            self.tearDownSuite()
        except:
            result.addError(self,self.__exc_info())
        return result

    def debug(self):
        """Run the tests without collecting errors in a TestResult"""
        self.setUpSuite()
        TestSuite.debug(self)
        self.tearDownSuite()

    def __exc_info(self): # copied from TestCase, FIXME: factor out.
        """Return a version of sys.exc_info() with the traceback frame
           minimised; usually the top level of the traceback frame is not
           needed.
        """
        import sys
        exctype, excvalue, tb = sys.exc_info()
        if sys.platform[:4] == 'java': ## tracebacks look different in Jython
            return (exctype, excvalue, tb)
        newtb = tb.tb_next
        if newtb is None:
            return (exctype, excvalue, tb)
        return (exctype, excvalue, newtb)

    def shortDescription(self): # needed when setUpSuite()/tearDownSuite() exception is reported.
        return str(self.__class__) # ok. for singletons.

    def addDefaultTestCases(self, testCaseClass):
        """ Use the defaultTestLoader to add test cases from the given TestCase subclass """
        for methodName in defaultTestLoader.getTestCaseNames(testCaseClass):
            self.addTest(testCaseClass(methodName))

Re: [Pyunit-interest] How to test a condition

[Fred L. D. Jr. <fd...@ac...>]

Jeremy Hylton writes:
 > And I'd still like to see a version of these methods that are in
 > positive form.  assert() is much clearer than failUnless().  Since
 > assert is not allowed (it's a keyword), I'd prefer something like
 > verify().  

  And I'd rather not change the API yet again.  ;-)  Having three
versions of each method would not help; there seems to be enough
confusion between the assert*() and fail() flavors we have today, and
we can't retract either of those from the standard library.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

Re: [Pyunit-interest] How to test a condition

[Steve P. <ste...@ya...>]

Jeremy Hylton wrote:
> >>>>> "SP" == Steve Purcell <ste...@ya...> writes:
>   SP> So the best idea is probably to favour the TestCase methods such
>   SP> as 'failUnless()' over the 'assert' statement.
> 
> And I'd still like to see a version of these methods that are in
> positive form.  assert() is much clearer than failUnless().  Since
> assert is not allowed (it's a keyword), I'd prefer something like
> verify().  


Actually, there has been an 'assert_()' since the first version, and the set
of such 'positive form' methods in TestCase is currently:

   assert_()
   assertEqual()
   assertNotEqual()
   assertRaises()

I think in terms of what might constitute a test failure, so I like to
use the 'fail()' methods. YMMV.

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
GPG fingerprint: EB79 2AB1 D494 16F9 8C3B  DAC6 5341 30CE BCCA EBEA

Re: [Pyunit-interest] How to test a condition

[Jeremy H. <je...@zo...>]

>>>>> "SP" == Steve Purcell <ste...@ya...> writes:

  SP> There was some discussion about the appropriateness of using
  SP> 'assert' and AssertionError when the Py2.1 integration was
  SP> made. PyUnit was modified so that a different error could be
  SP> used to indicate failure at a later date if Python's 'assert'
  SP> and optimisation behaviour is altered.

  SP> So the best idea is probably to favour the TestCase methods such
  SP> as 'failUnless()' over the 'assert' statement.

And I'd still like to see a version of these methods that are in
positive form.  assert() is much clearer than failUnless().  Since
assert is not allowed (it's a keyword), I'd prefer something like
verify().  

Jeremy

Re: [Pyunit-interest] How to test a condition

[Chuck E. <Chu...@ya...>]

At 03:17 PM 9/2/2001 +0200, Steve Purcell wrote:
>Yes they are. I'm guilty of writing the separate pyunit docs, and Fred Drake
>wrote the standard library docs for the unittest module.
>
>There was some discussion about the appropriateness of using 'assert' and
>AssertionError when the Py2.1 integration was made. PyUnit was modified so
>that a different error could be used to indicate failure at a later date
>if Python's 'assert' and optimisation behaviour is altered.
>
>So the best idea is probably to favour the TestCase methods such as
>'failUnless()' over the 'assert' statement.
>
>However, I still use the 'assert' statement when I feel like it, and when
>I don't plan to run tests with Python's -O optimisation enabled.
>
>How's that for muddying the waters? :-)

Pretty good.  ;-)

But at least I have an idea of where things stand. The differences made me 
curious.


Thanks,
-Chuck

Re: [Pyunit-interest] How to test a condition

[Steve P. <ste...@ya...>]

Chuck Esterbrook wrote:
> The Py 2.1 docs direct the user to use self.failUnless() while the online 
> docs at pyunit.sourceforge.net make it clear that using the assert 
> statement is simple, easy and normal.
> 
> Since the latest pyunit was released post-Py 2.1, does this imply that Py 
> 2.2 will also lean towards the assert statement?
> 
> I'm curious: Are the docs for unittest at Python and at pyunit maintained 
> separately?


Yes they are. I'm guilty of writing the separate pyunit docs, and Fred Drake
wrote the standard library docs for the unittest module.

There was some discussion about the appropriateness of using 'assert' and
AssertionError when the Py2.1 integration was made. PyUnit was modified so
that a different error could be used to indicate failure at a later date
if Python's 'assert' and optimisation behaviour is altered.

So the best idea is probably to favour the TestCase methods such as
'failUnless()' over the 'assert' statement.

However, I still use the 'assert' statement when I feel like it, and when
I don't plan to run tests with Python's -O optimisation enabled.

How's that for muddying the waters? :-)

-Steve


-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
GPG fingerprint: EB79 2AB1 D494 16F9 8C3B  DAC6 5341 30CE BCCA EBEA

Re: [Pyunit-interest] Traceback objects stored in PyUnit error lists

[Jeremy H. <je...@zo...>]

>>>>> "SP" == Steve Purcell <ste...@ya...> writes:

  SP> My idea was that the traceback object could later be inspected
  SP> in a fancy TestRunner in order to see the local variables at the
  SP> time the error occurred.

At Zope Corp., there is a strong interest in being able to use Python
debuggers to debug failed unit tests.  So I'm in favor of a solution
that allows this to happen.

  SP> On the other hand, it seems that in certain cases the prevention
  SP> of garbage collection causes unexpected consequences; if GC is
  SP> relied upon to, say, close a file opened by a test case, then
  SP> the file will not be closed before the next test is
  SP> executed. Tracking down subsequent misbehaviour can then be
  SP> tricky, as it always is with reference-counting issues.

In particular, it was a problem on Windows where an open file can not
be removed (os.remove/unlink).  If you only run the tests on Unix,
you'll never run into the problem.  On the other hand, I've found a
lot of unexpected problems porting unittests developed on Unix to
Windows. 

  SP> Jeremy Hylton was caught out by this [1] and he proposed that
  SP> the traceback instead be formatted directly into a string at the
  SP> time the error occurs.

  SP> Such a change would potentially affect those who have written
  SP> custom TestRunner or TestResult classes, and would probably rule
  SP> out the inspection behaviour described above.

Actually, I suggested an alternative that doesn't rule out the
inspection behavior, but does change the way its made available.  A
custom test runner could override the addError/addFailure methods and
do something with the traceback object there.

I'm skeptical that a traceback object inspected at the end of a large
collection of tests would still contain useful information.  Mutable
objects could be changed by a tearDown() method or by subsequent
tests.  If you're going to debug a failed test, you ought to do it
when the error occurs and the whole call chain is still available.

  SP> 2. Do you have custom TestRunner code that would be affected by
  SP>     such a change?

If so, I'd be interested to know whether its useful to jump into the
debugger at the end?  How hard would it be to adapt to fall into the
debugger at the time of the error?

Jeremy

Re: [Pyunit-interest] Traceback objects stored in PyUnit error lists

[Fred L. D. Jr. <fd...@ac...>]

Steve Purcell writes:
 >  1. Have you ever been bitten by the unexpected lack of garbage collection?

  Not directly, but I think this will bite Windows users more than
Unix users.  The problem is that open files have more consequences on
Windows than on Unix (you can't rename or unlink it), so there are
more ways for open file objects to cause failures there.

 >  2. Do you have custom TestRunner code that would be affected by such a
 >     change?

  I don't think so, but if so, they can be fixed easily enough.  For
people that want to use the exception for debugging support, it
probably makes more sense to debug immediately rather than storage a
bunch of tracebacks to the end.  For just about any package, it is
very easy to have side effects (intentional or otherwise) that affect
the objects referenced by stored tracebacks, so debugging using the
stored traceback is less effective than debugging immediately.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

[Pyunit-interest] Traceback objects stored in PyUnit error lists

[Steve P. <ste...@ya...>]

Hi folks,

I'd like some feedback on the following if it affects any of you.

When an error or failure occurs during the running of a test case, PyUnit
stores the error in the current TestResult as a '(testcase, exceptioninfo)'
tuple, where 'exceptioninfo' contains (among other things) a traceback
object. (This has been the case since the first release.)

My idea was that the traceback object could later be inspected in a
fancy TestRunner in order to see the local variables at the time the error
occurred.

Storing the traceback like this prevents garbage collection of the
associated items, but only for failed tests; I believed was not a big
problem, and worth the possible benefit of having the stack information
later.

On the other hand, it seems that in certain cases the prevention of garbage
collection causes unexpected consequences; if GC is relied upon to, say,
close a file opened by a test case, then the file will not be closed before
the next test is executed. Tracking down subsequent misbehaviour can then
be tricky, as it always is with reference-counting issues.

Jeremy Hylton was caught out by this [1] and he proposed that the
traceback instead be formatted directly into a string at the time the
error occurs.

Such a change would potentially affect those who have written custom
TestRunner or TestResult classes, and would probably rule out the
inspection behaviour described above.

I would like to avoid making incompatible changes, and I'd like to know from
the members of the list:

 1. Have you ever been bitten by the unexpected lack of garbage collection?
 2. Do you have custom TestRunner code that would be affected by such a
    change?

Any wisdom you can offer would be appreciated!

Thanks,

-Steve

References:
[1] http://sf.net/tracker/?func=detail&aid=451309&group_id=5470&atid=105470

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
GPG fingerprint: EB79 2AB1 D494 16F9 8C3B  DAC6 5341 30CE BCCA EBEA

[Pyunit-interest] Re: Pyunit for Jython & wxPython?

[Dave K. <dk...@bi...>]

Steve Purcell <ste...@ya...> wrote:
>
> > Similarly there was some discussion of a wxPython version of the GUI,
> > also over a year ago.  Is there any possibility of a wxPython GUI being
> > included in the standard distribution?
> 
> Quite possibly, but again, I'd distribute it separately. I like the idea of
> keeping one package that works with 'vanilla' Python, and separate packages
> for code with more fiddly dependencies.

I was thinking along the lines of having them in separate distributions,
but all hosted on the pyunit site.  If I did work on either of the GUIs,
would you be willing to host them?

> 
> > If no-one else is working on either of these then I may have a go, but
> > my free time is limited and I dont want to spend it re-inventing the
> > wheel.
> 
> I started writing a GTK GUI, but didn't get around to finishing it. You're
> welcome to have a go. It should (in theory) be possible to just subclass
> unittest.BaseGUITestRunner.

Nathan Heagy emailed me to say he had had a working wxPython GUI
version, but he lost it when his hard-drive died.  He thinks there may
be copies out in the wild, so if anyone on the list has a copy then I
would grateful if they got in touch. 

Regards,

	Dave Kirby

Re: [Pyunit-interest] Pyunit for Jython & wxPython?

[Steve P. <ste...@ya...>]

Hi Dave,

Dave Kirby wrote:
> What is the status of using PyUnit with Jython (formerly JPython)?  I
> see from the archive that there has been some discussion in the past,
> but that was a year ago, and only used the textRunner.  Is the latest
> version of PyUnit compatible with Jython?

It certainly is. Or, at least, I haven't heard any complaints. :-)

> Has anyone done a Swing GUI for it?

Not that I'm aware of, no.

> If so is there any chance of it being included in the official
> release of PyUnit?

If such a GUI existed, I would probably prefer to distribute it separately,
rather than with the core modules.

> Similarly there was some discussion of a wxPython version of the GUI,
> also over a year ago.  Is there any possibility of a wxPython GUI being
> included in the standard distribution?

Quite possibly, but again, I'd distribute it separately. I like the idea of
keeping one package that works with 'vanilla' Python, and separate packages
for code with more fiddly dependencies.

> If no-one else is working on either of these then I may have a go, but
> my free time is limited and I dont want to spend it re-inventing the
> wheel.

I started writing a GTK GUI, but didn't get around to finishing it. You're
welcome to have a go. It should (in theory) be possible to just subclass
unittest.BaseGUITestRunner.

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
GPG fingerprint: EB79 2AB1 D494 16F9 8C3B  DAC6 5341 30CE BCCA EBEA

[Pyunit-interest] Pyunit for Jython & wxPython?

[Dave K. <dk...@bi...>]

What is the status of using PyUnit with Jython (formerly JPython)?  I
see from the archive that there has been some discussion in the past,
but that was a year ago, and only used the textRunner.  Is the latest
version of PyUnit compatible with Jython?  Has anyone done a Swing GUI
for it?  If so is there any chance of it being included in the official
release of PyUnit?

Similarly there was some discussion of a wxPython version of the GUI,
also over a year ago.  Is there any possibility of a wxPython GUI being
included in the standard distribution?

If no-one else is working on either of these then I may have a go, but
my free time is limited and I dont want to spend it re-inventing the
wheel.

Regards,

	Dave Kirby