pyunit-interest

Re: [Pyunit-interest] pyunit version with python 2.2.1

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

Markus Jais writes:
 > with python 2.2.1 comes a version
 > __version__ = "$Revision: 1.14 $"[11:-2]
 > 
 > according to the sources. but version 1.4.1 is already from august last year
 > AFAIK.
 > 
 > is there a reason why there is still the version 1.14 in the python
 > distribution??

These version numbers are inserted by the revision control software,
and do not reflect the larger versioning picture.  Since Python and
PyUNIT are maintained in two distinct repositories, the version that
has been integrated into Python should be changed to show the same
version number as that in PyUNIT (probably by removing or changing the
"magic" that causes CVS to insert the revision number).

I'll try to look into this later tonight.


  -Fred

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

[Pyunit-interest] pyunit version with python 2.2.1

[Markus J. <in...@mj...>]

hello

with python 2.2.1 comes a version
__version__ = "$Revision: 1.14 $"[11:-2]

according to the sources. but version 1.4.1 is already from august last year
AFAIK.

is there a reason why there is still the version 1.14 in the python
distribution??

if version 1.4.1 is better, can I just delete unittest.py from
/usr/local/lib/python2.2
and reinstall the new version ??

thanks in advance

markus

--
Markus Jais
http://www.mjais.de
in...@mj...
The road goes ever on and on - Bilbo Baggins

Re: [Pyunit-interest] Namespace bug in unittest?

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

Hello Andy,

As you may have discovered, this behavior has nothing to do with unittest as
the following illustrates:

class SweepQueue:
    def __init__(self, initialQueue=[]):
## Problem also appears to be in the following lines:
##      The following line causes a failure
        self.pQueue = initialQueue
##      The following line allows the tests to succeed
##      self.pQueue = []

    def insert(self, sp):
        self.pQueue.append(sp)

def badQueuePolygonPoints(swpq):
    badPoint = (999,998,"badtype")
### This line causes the contamination somehow ...
    swpq.insert(badPoint)


o = SweepQueue()
print o.pQueue

badQueuePolygonPoints(o)
print o.pQueue

o = SweepQueue()
print o.pQueue

output from above:

[]
[(999, 998, 'badtype')]
[(999, 998, 'badtype')]

Rather, it is a feature of Python. Default arguments, like initialQueue=[],
are evaluated exactly **once** and not every time the procedure is called.
If you want a new list, each time a procedure is called, you must, as you
have discovered, explicitly say so in the body of the procedure.

Hopes this helps.

-- jv

----- Original Message -----
From: "Andrew P. Lentvorski" <bs...@al...>
To: <pyu...@li...>
Cc: "Andrew P. Lentvorski" <bs...@al...>
Sent: Sunday, May 05, 2002 3:49 AM
Subject: [Pyunit-interest] Namespace bug in unittest?


> Hi, all,
>
> I am having some fairly strange problems with unittest and program state
> somehow moving between unit tests with no obvious (to me, at least)
> mechanism to cause it.
>
> I have attached the file.  It has the unit tests as well as some comments
> in it.  I managed to whittle it down to only 42 lines, but I'm really
> stuck at this point.
>
> My python is:
> Python 2.2.1 (#1, Apr 18 2002, 01:20:57)
> [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
>
> I was hoping that one of the unittest experts could look at it and tell me
> if I'm doing something truly idiotic or if it really is a bug.
>
> Thanks,
> Andy L.
>

[Pyunit-interest] Namespace bug in unittest?

[Andrew P. L. <bs...@al...>]

Hi, all,

I am having some fairly strange problems with unittest and program state
somehow moving between unit tests with no obvious (to me, at least)
mechanism to cause it.

I have attached the file.  It has the unit tests as well as some comments
in it.  I managed to whittle it down to only 42 lines, but I'm really
stuck at this point.

My python is:
Python 2.2.1 (#1, Apr 18 2002, 01:20:57)
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4

I was hoping that one of the unittest experts could look at it and tell me
if I'm doing something truly idiotic or if it really is a bug.

Thanks,
Andy L.

[Pyunit-interest] Mock object Tutorial

[Changjune K. <jun...@ha...>]

I have just finished writing it. You can get the mockobject module that I
wrote, on the page as well:
http://no-smok.net/seminar/moin.cgi/PythonMockObjectTutorial

June

RE: [Pyunit-interest] TestDrivenDevelopment in Python

[Patrick K. O'B. <po...@or...>]

Very nice!

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyu...@li...
> [mailto:pyu...@li...]On Behalf Of
> Changjune Kim
> Sent: Friday, April 19, 2002 10:03 AM
> To: pyu...@li...
> Subject: [Pyunit-interest] TestDrivenDevelopment in Python
> 
> 
> I'm writing an article about TDD in Python. It's a work in 
> progress. (half the
> way through now) It uses Steve's unittest module. (thanks Steve!)
> 
> http://zeropage.org/moin/moin.cgi/TestDrivenDevelopment
> 
> any comments are welcome.
> 
> I'm going to write a tutorial about using my mockobject module with TDD
> tonight, hopefully.
> 
> June
> 
> 
> 
> 
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyunit-interest

[Pyunit-interest] TestDrivenDevelopment in Python

[Changjune K. <jun...@ha...>]

I'm writing an article about TDD in Python. It's a work in progress. (half the
way through now) It uses Steve's unittest module. (thanks Steve!)

http://zeropage.org/moin/moin.cgi/TestDrivenDevelopment

any comments are welcome.

I'm going to write a tutorial about using my mockobject module with TDD
tonight, hopefully.

June

Re: [Pyunit-interest] PyUnit and Mock Object

[Changjune K. <jun...@ha...>]

----- Original Message -----
From: "Shae Erisson" <sh...@we...>
To: <joe...@ho...>
Cc: <pyu...@li...>
Sent: Friday, April 19, 2002 7:28 PM
Subject: Re: [Pyunit-interest] PyUnit and Mock Object


> From: "Joel Quinet" <joe...@ho...>
> Subject: [Pyunit-interest] PyUnit and Mock Object
> Date: Fri, 19 Apr 2002 12:03:52 +0200
>
> > Hi all,
> >
> > I have red some articles on the mock object, it seems to be a good thing
for
> > unit testing.
> > They write about module available to do mock objects in Java, C++, etc...
> > but never in Python.
> >
> > Is there somewhere a mock module for Python ?  Is it working with PyUnit ?
>
> As mentioned in this email:
>
> http://mail.python.org/pipermail/python-list/2001-March/035546.html
>
> you can get mock objects from:
>
> http://groups.yahoo.com/group/extremeprogramming/files/
>
> filename is PythonMock.zip
>
> for some reason, the direct url doesn't work, so you have to go to that page
first.
>
> I haven't tried this code, if anyone else knows about this or other Mock
> Objects for Python, I'd like to hear about it.

I have usedd this module for some months and unsatisfied with it,
made Python version of MockObject framework for java at
http://www.mockobjects.com .

Anyone interested in trying it, I'll send you the module.

June

>
> Thanks,
> ----
> Shae Matijs Erisson - http://www.webwitches.com/~shae/
> <radix> shapr: I think you *are* a purist :)
> <radix> shapr: it's just that you're morally against unstable software,
instead
>         of morally against MS, or non-free software, or whatnot.
>
>
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyunit-interest
>

Re: [Pyunit-interest] PyUnit and Mock Object

[Shae E. <sh...@we...>]

From: "Joel Quinet" <joe...@ho...>
Subject: [Pyunit-interest] PyUnit and Mock Object
Date: Fri, 19 Apr 2002 12:03:52 +0200

> Hi all,
> 
> I have red some articles on the mock object, it seems to be a good thing for
> unit testing.
> They write about module available to do mock objects in Java, C++, etc...
> but never in Python.
> 
> Is there somewhere a mock module for Python ?  Is it working with PyUnit ?

As mentioned in this email:

http://mail.python.org/pipermail/python-list/2001-March/035546.html

you can get mock objects from:

http://groups.yahoo.com/group/extremeprogramming/files/

filename is PythonMock.zip

for some reason, the direct url doesn't work, so you have to go to that page first.

I haven't tried this code, if anyone else knows about this or other Mock
Objects for Python, I'd like to hear about it.

Thanks,
----
Shae Matijs Erisson - http://www.webwitches.com/~shae/
<radix> shapr: I think you *are* a purist :)
<radix> shapr: it's just that you're morally against unstable software, instead
        of morally against MS, or non-free software, or whatnot.

[Pyunit-interest] PyUnit and Mock Object

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

Hi all,

I have red some articles on the mock object, it seems to be a good thing for
unit testing.
They write about module available to do mock objects in Java, C++, etc...
but never in Python.

Is there somewhere a mock module for Python ?  Is it working with PyUnit ?

Thanks.
Joel

Re: [Pyunit-interest] test case independence

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

Hi J.D.,

Response in-line below....


J.D. Hollis wrote:
> class SeedTestCase(unittest.TestCase):
>     "Test cases for class Seed"
>     
>     def setUp(self):
>         self.seed = db.Seed('name')
>         
>     [snip]
>
>     def testGetValueFailure(self):
>         """Tests whether Seed.getValue() raises an exception when it
> can't find key"""
>         self.assertRaises(db.NoSuchKeyError, self.seed.getValue, 'key')
> 
> def testSuite():
>     return unittest.makeSuite(SeedTestCase, 'test')
> 
> I'm invoking the test runner in the python shell using
> 'runner.run(dbtest.testSuite())' and testGetValueFailure() is failing:
> 
> ======================================================================
> FAIL: Tests whether Seed.getValue() raises an exception when it can't
> find key
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "C:\Documents and Settings\J.D. Hollis\My
> Documents\garden\plant\dbtest.py", line 41, in testGetValueFailure
>     self.assertRaises(db.NoSuchKeyError, self.seed.getValue, 'key')
>   File "C:\Python22\lib\unittest.py", line 279, in failUnlessRaises
>     raise self.failureException, excName
> AssertionError: NoSuchKeyError



Well, 'self.seed' will certainly be created freshly by the 'setUp()'
method just before 'testGetValueFailure()' is run, so I think that
is not the problem, assuming 'db.Seed()' works correctly. To double-check,
I think that if you add the "self.seed = db.Seed('name')" line to the
'testGetValueFailure()' method, the same thing will happen.

Now, when 'assertRaises()' fails, it prints the name of the unexpected
exception it caught. In your case, it prints 'NoSuchKeyError', so
my guess is that for some reason 'db.NoSuchKeyError' in the test
script is not equal to the 'NoSuchKeyError' in the 'db' module.

This has caught me out sometimes in Python, but I forget right now
how it comes about.

I remember having to change code in 'unittest.py' for exactly that reason:

This:
        if type(obj) == types.ModuleType:
            return self.loadTestsFromModule(obj)
        elif type(obj) == types.ClassType and issubclass(obj, TestCase):
            return self.loadTestsFromTestCase(obj)

Became this:
        import unittest
        if type(obj) == types.ModuleType:
            return self.loadTestsFromModule(obj)
        elif type(obj) == types.ClassType and issubclass(obj, unittest.TestCase):
            return self.loadTestsFromTestCase(obj)

Hope that helps somewhat.

Best wishes,

-Steve


-- 
Steve Purcell
http://advogato.org/person/purcell

[Pyunit-interest] test case independence

[J.D. H. <gt...@ma...>]

I'm having some problems with my unit tests failing on working code (the
code I'm testing is rather trivial code that I was using to teach myself
pyunit with).  It seems to me that for some reason the tests in the test
case are stepping on each other, but then this is my first time using
pyunit specifically and unit testing in general.  Here's the test code:

class SeedTestCase(unittest.TestCase):
    "Test cases for class Seed"
    
    def setUp(self):
        self.seed = db.Seed('name')
        
    def tearDown(self):
        self.seed = None
        
    def testSeed(self):
        """Tests whether Seed.__str__() returns the proper string"""
        self.assertEqual(self.seed.__str__(), 'name')
        
    def testName(self):
        """Tests whether Seed.name() returns the name string"""
        self.assertEqual(self.seed.name(), 'name')

    def testSetValue(self):
        """Tests whether Seed.setValue() successfully sets or adds a
value to Seed"""
        self.seed.setValue('key', 'foo')
        self.assertEqual(self.seed.getValue('key'), 'foo')

    def testAddNewValue(self):
        """Tests whether Seed.addValue() can add a value to Seed"""
        self.seed.addValue('key', 'value')
        self.assertEqual(self.seed.getValue('key'), 'value')

    def testAddExistingValue(self):
        """Tests whether Seed.addValue() raises an exception when trying
to add with an existing key"""
        self.seed.addValue('key', 'value')
        self.assertRaises(db.KeyExistsError, self.seed.addValue, 'key',
'foo')
        self.assertEquals(self.seed.getValue('key'), 'value')

    def testGetValueFailure(self):
        """Tests whether Seed.getValue() raises an exception when it
can't find key"""
        self.assertRaises(db.NoSuchKeyError, self.seed.getValue, 'key')

    #def testDelValue(self):
    #    """Tests whether Seed.delValue() can remove a key:value
    
def testSuite():
    return unittest.makeSuite(SeedTestCase, 'test')

I'm invoking the test runner in the python shell using
'runner.run(dbtest.testSuite())' and testGetValueFailure() is failing:

======================================================================
FAIL: Tests whether Seed.getValue() raises an exception when it can't
find key
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Documents and Settings\J.D. Hollis\My
Documents\garden\plant\dbtest.py", line 41, in testGetValueFailure
    self.assertRaises(db.NoSuchKeyError, self.seed.getValue, 'key')
  File "C:\Python22\lib\unittest.py", line 279, in failUnlessRaises
    raise self.failureException, excName
AssertionError: NoSuchKeyError

----------------------------------------------------------------------

That shouldn't happen (I don't think), assuming we're testing a newly
created data structure.  Any help is appreciated, either with the design
of my unit tests, or with why they're failing.

Cheers,
J.D.

Re: [Pyunit-interest] Anyone have/thought about a more "program friendly" TestRunner

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

John Ziniti wrote:
> I am picturing a TestRunner which returns the test results
> in some sort of tuple with all the information.

Hi John,

How about:

   s = MySuite()
   result = unittest.TestResult()
   s.run(result)

after which you can inspect the following attributes of 'result': 'errors',
'failures', 'testsRun'

I think that should do what you want.

Very best wishes,

-Steve

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

[Pyunit-interest] Anyone have/thought about a more "program friendly" TestRunner

[John Z. <jz...@sp...>]

I am trying to use PyUnit in a testing framework where
I don't really have access to sys.stdout/stderr during the
running of the tests, and I can't really remap those streams
to a StringIO either,  so TextTestRunner is not really
doing the job for me.

I am picturing a TestRunner which returns the test results
in some sort of tuple with all the information.

Has anyone else given any thought/code to this?

TIA,

John Ziniti

RE: [Pyunit-interest] Re: Run all tests in the current directory

[Patrick K. O'B. <po...@or...>]

Email line wrapping messed up the formatting of the original bit of code
that I sent to the list. It sounds you've got things figured out now. If you
run into a snag, holler.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyu...@li...
> [mailto:pyu...@li...]On Behalf Of Ken
> Causey
> Sent: Tuesday, March 19, 2002 4:12 PM
> To: pyu...@li...
> Subject: [Pyunit-interest] Re: Run all tests in the current directory
>
>
> OK, looks like my problem was a formatting issue, the addTest message
> needs to be called after each __import__ therefore it should be in the
> for loop.  Simple enough to fix, now I think I really am in business.
>
> Thanks all.
>
> Ken
>
>
>
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyunit-interest

[Pyunit-interest] Re: Run all tests in the current directory

[Ken C. <ke...@in...>]

OK, looks like my problem was a formatting issue, the addTest message
needs to be called after each __import__ therefore it should be in the
for loop.  Simple enough to fix, now I think I really am in business.

Thanks all.

Ken

Re: [Pyunit-interest] Run all tests in the current directory

[Ken C. <ke...@in...>]

I'm having some trouble with this script, it only seems to run the tests
from the last module loaded.  Here's my version with some debugging
added:

ken@temp:~/temp$ cat pytest.py
#!/usr/bin/env python2.2

import unittest
import glob
import os
import sys

def suite():
   sys.path.append('.')
   for filename in glob.glob('test_*.py'):
        print "Importing %s..." % (filename)
        module = __import__(os.path.splitext(filename)[0])
        print "Directory: %s" % (str(dir(module)))

   print "Final Directory: %s" % (str(dir(module)))
   suite = unittest.TestSuite()
   suite.addTest(unittest.defaultTestLoader.loadTestsFromModule(module))
   print "Loaded a total of %d test cases." % (suite.countTestCases())
   return suite
    

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

I'm using the testcase example included in the python2.2-unit debian
package:

ken@temp:~/temp$ ls -l test_*.py
-rw-r--r--    1 ken      ken          2510 Mar 19 14:47 test_lists.py
-rw-r--r--    1 ken      ken           538 Mar 19 14:45 test_many.py
-rwxr-xr-x    1 ken      ken          1664 Mar 19 14:46 test_widget.py

Renamed of course to work with this script.

Here's what I get:

ken@temp:~/temp$ ./pytest.py
Importing test_lists.py...
Directory: ['ListTestCase', 'UserList', 'UserListTestCase',
'__builtins__', '__doc__', '__file__', '__name__', 'unittest']
Importing test_many.py...
Directory: ['ProlificTestCase', '__builtins__', '__doc__', '__file__',
'__name__', 'unittest']
Importing test_widget.py...
Directory: ['Widget', 'WidgetTestCase', '__builtins__', '__doc__',
'__file__', '__name__', 'unittest']
Final Directory: ['Widget', 'WidgetTestCase', '__builtins__', '__doc__',
'__file__', '__name__', 'unittest']
Loaded a total of 2 test cases.
.F
======================================================================
FAIL: Resizing of widgets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test_widget.py", line 28, in testResize
    assert self.widget.size() == (100,150), \
AssertionError: wrong size after resize

----------------------------------------------------------------------
Ran 2 tests in 0.003s

FAILED (failures=1)

As you can see the namespace seems to be getting replaced each time
__import__ is called.  Is this normal?  Change with 2.2 maybe?

Ken

Re: [Pyunit-interest] [Stupid Newbie Question] How do I use it?

[Ken C. <ke...@in...>]

If you don't mind I think I will reply to myself again, sigh.

As you may have imagined from looking at the code I just posted after
starting with Patrick O'Brien's code I went in several wrong
directions.  After sending off that email I happened to glance back at
Patrick's original code and realize that I had deviated quite severely
and unnecessarily from his methodology, so here's a version much more
like Patrick's and more sensible:

ken@temp:~/temp$ cat testem.py
#!/usr/bin/env python2.2

import unittest
import unittestgui
import glob
import os

def suite():
        for filename in glob.glob('test_*.py'):
            module = __import__(os.path.splitext(filename)[0])

        suite = unittest.TestSuite()
	suite.addTest(unittest.defaultTestLoader.loadTestsFromModule(module)
        return suite
    

if __name__ == '__main__':
    unittestgui.main('testem.suite')

Re: [Pyunit-interest] [Stupid Newbie Question] How do I use it?

[Ken C. <ke...@in...>]

Well, I guess I'll reply to my own post.

After posting my reply I noticed Patrick O'Brien's script and wondered
if I could start with that and make something that would use unittestgui
rather than the command line runner.  It seems a bit kludgy yet and I
haven't tested it thorougly, but here's what I've come up with that
seems to work:

ken@temp:~/temp$ cat testem.py
#!/usr/bin/env python2.2

__author__ = "Patrick K. O'Brien <<EMAIL: PROTECTED>>"
__cvsid__ = "$Id: testall.py,v 1.1 2002/03/14 23:10:20 pobrien Exp $"
__revision__ = "$Revision: 1.1 $"[11:-2]


import unittest
import unittestgui
import glob
import os

class Suite:

    def __call__(self):
        for filename in glob.glob('test_*.py'):
            module = __import__(os.path.splitext(filename)[0])

        suite = unittest.TestSuite()
       
suite.addTest(unittest.defaultTestLoader.loadTestsFromModule(module))
        return suite


suite = Suite()

if __name__ == '__main__':
    unittestgui.main('testem.suite')


Now that I paste this into an email I see it has a dependency on the
name of the module, but I suppose that could be fixed easily enough.

It seems to me that unittestgui needs to not restrict itself to strings
as it does.

Ken

[Pyunit-interest] [Stupid Newbie Question] How do I use it?

[Ken C. <ke...@in...>]

So I've been studying XP and now it's time to start using it.  I'm using
Debian unstable so I apt-get python2.2-unit and python2.2-tk (by the
way, if the Debian maintainer for python2.2-unit reads this,
python2.2-tk should probably be in Recommends:) and I'm ready to rock
right?

Somehow I'm missing something...

Here's how I thought that I would use it:

I'm working on my project, time to run a test, bells and whistles are
fun so I'll use the tkinter gui

python2.2 /usr/lib/python2.2/site-package/unittestgui.py
mytests.MyTestCase

This is not exactly pretty but to make it better I understand I would
need to make a little scriplet or install unittestgui in the PATH or
something, no big deal.

However, I get an error because unittestgui can't find my test class. 
Of course... the current directory is not in sys.path so it's not
finding my module.

Anyway, it sure looks like I'm going to have to spend a little time to
either write a little executable for each of my projects, or spend a
little more time and come up with a more general solution that I can
just place in the PATH.

Has anyone already done this?  Or am I just missing the boat here?  Am I
misunderstanding something fundamental about the usage of unittest? 
Feel free to clue me in.

Ken Causey
ke...@in...

P.S. I'm not on the list so please be sure to respond directly to me as
appropriate.

[Pyunit-interest] How should I handle tests under different versions of Python

[Patrick K. O'B. <po...@or...>]

Are there any "standards" for writing unit tests that adapt to the specific
version of Python being used to run the tests?

Here is my situation. I'm adding unit tests to my PyCrust package, which is
a Python shell that is similar to IDLE but uses wxPython instead of Tk.
PyCrust includes certain introspection functions to support the display of
command completion and call tips and a namespace tree view. These
introspection routines should work on any Python object from any Python
version back to 2.0 (at least in theory, but I'm adding the unit tests to
make sure this is the case).

In order to test the introspection routines against a variety of objects, I
want to define some support classes (that make use of the new Python types)
inside my unit test module. For example:

class A(object):
    def __init__(self, a):
        self.a = a
    def foo(self):
        return "A"

class B(A):
    def __init__(self, b):
        self.b = b
    def foo(self):
        return "B" + super(B, self).foo()

class C(A):
    def foo(self):
        return "C" + super(C, self).foo()

class D(C, B):
    def foo(self):
        return "D" + super(D, self).foo()

But as soon as I do that the tests will fail to run under Python 2.1, where
"object" and "super" do not exist. For whatever reason I can't think of an
elegant way to handle this. And I was hoping someone who had already dealt
with this could suggest an approach that fit nicely within the whole unit
testing philosophy. Any suggestions?

Thanks.

---
Patrick K. O'Brien
Orbtech

Re: [Pyunit-interest] Run all tests in the current directory

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

On Thu, 14 Mar 2002 18:42:00 -0600
 "Patrick K. O'Brien" <po...@or...> wrote:
> A bit heavier than what I was after. But very nice. Lots
> of good ideas in
> there. I'm sure I'll have more of a need for these
> features as my set of
> tests grows. Thanks for the tip.

It is certainly a complicated script.  And you're right that
the features may be useful as your test suite grows.  We
ended up needing these features on projects with large
and/or slow test suites.  Zope has 1200 unit tests.  An
internal project had functional tests driven by unittest
that took several minutes to run.  

Using regexs to select test suites and cases was probably
the most useful feature.  We had a few isolated tests that
failed intermittently.  We could use the basic test harness
to select those tests, run them in a loop, and print
tracebacks as soon as they happend.  It was the only sane
alternative :-).

Jeremy

RE: [Pyunit-interest] Run all tests in the current directory

[Patrick K. O'B. <po...@or...>]

A bit heavier than what I was after. But very nice. Lots of good ideas in
there. I'm sure I'll have more of a need for these features as my set of
tests grows. Thanks for the tip.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyu...@li...
> [mailto:pyu...@li...]On Behalf Of Jeremy
> Hylton
> Sent: Thursday, March 14, 2002 6:16 PM
> To: po...@or...; Sean Allen; PyUnit
> Subject: Re: [Pyunit-interest] Run all tests in the current directory
>
>
> There's a fairly elaborate test driver that we use for Zope
> and StandaloneZODB.  It's basic function is to find all the
> unittest suites in a large collection of Python packages,
> based on a few simple naming conventions.  Test suites are
> contained in subpackages named tests, in module with names
> that start with 'test'.  Each module has a function
> test_suite() that returns the unittest suite.
>
> It's got a bunch of other handy features:
>
> - connected to distutils setup/build commands
> - use regexes to specify particular modules or tests methods
> - print tracebacks immediately, rather than at the end (very
> handy when the full test suite takes 5-10 minutes)
> - run the tests in a loop to look for memory leaks
>
> You can find it at cvs.zope.org.  Look for Zope3/test.py on
> the Zope-3x-branch or StandaloneZODB/test.py on the trunk.
>
> Jeremy
>
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyunit-interest

Re: [Pyunit-interest] Run all tests in the current directory

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

There's a fairly elaborate test driver that we use for Zope
and StandaloneZODB.  It's basic function is to find all the
unittest suites in a large collection of Python packages,
based on a few simple naming conventions.  Test suites are
contained in subpackages named tests, in module with names
that start with 'test'.  Each module has a function
test_suite() that returns the unittest suite.

It's got a bunch of other handy features:

- connected to distutils setup/build commands
- use regexes to specify particular modules or tests methods
- print tracebacks immediately, rather than at the end (very
handy when the full test suite takes 5-10 minutes)
- run the tests in a loop to look for memory leaks

You can find it at cvs.zope.org.  Look for Zope3/test.py on
the Zope-3x-branch or StandaloneZODB/test.py on the trunk.

Jeremy

RE: [Pyunit-interest] Run all tests in the current directory

[Patrick K. O'B. <po...@or...>]

> On Thu, 2002-03-14 at 15:23, Patrick K. O'Brien wrote:
> > I have a tests directory containing a number of unittest test
> modules and
> > wanted an easy way to run every single test without having to
> create suites
> > in each module. Since I couldn't find anything like this in the docs, in
> > anyone else's code, or on the Python Cookbook.
> <snip/>
>
> FWIW, in the pybeep project (http://pybeep.sourceforge.net) we use a
> similar script (CVSROOT/test/testall.py), liberally filched from Mark
> Pilgrims most excellent Dive into Python
> (http://diveintopython.org/regression_divein.html)
>
> Sean Allen

I missed Mark's version when I was looking for something like this. Thanks
for the link. And Mark's version puts mine to shame - his uses regular
expressions, filter, lambda and map (three times, no less) to do the exact
same thing. <0.5 wink>

---
Patrick K. O'Brien
Orbtech