pyunit-interest

[Pyunit-interest] Re: Pyunit-interest digest, Vol 1 #27 - 1 msg

[Pieter N. <pi...@na...>]

On Mon, 20 Nov 2000 pyu...@li... wrote:

> Hi; the problem is that the __init__ method in TestCase takes a parameter
> that is the name of the test method that will be run by the instance.

I wonder whether this isn't an aspect of the API that can be
improved?

Often tests are simpler if they take constructor and then you create
a test for each possible combination of what you want to test, ie:

    from operator import *

    for _class in (Point, Size):
        for _op in (mul, div, add, sub):
            testSuite.add(VectorMathTestCase(_class, _op))

The fact that the tests must inherit from a TestCase base class makes
it more difficult to do such things, since the base class has a
constructor and semantics that must be maintained.

Wouldn't it be better if, instead of test inheriting from TestCase
so that you can ask a test: "Hey you! Inspect yourself for test
methods and run yourself!", you just hand the test runner an
arbitrary class and as *it*: "Here's a class. Inspect it for checkXXX
methods and run them".

I think the XUnit community has fallen into the trap of thinking that
Kent Beck's original SUnit interface (from which PyUnit and all the
others derive) is somehow a perfect API that is set in stone. Knowing
Beck's Extreme Programming approach, he would not have done "Big
Design Up Front" to come up with a perfect test API, but simply did
"The Simplest Thing that Could Possibly Work" - but thereafter, as he
needed to extend it, keep refactoring it so that it stays simple and
clean.

I think that:

  - The SUnit which Kent's group use internally is by now nothing
    like the original one they published, and

  - The XUnit community might have got themselves stuck on the 
    "simplest thing that could possibly work", minus the benefit of
    later refactorings, on the false assumption that they've been
    handed an API that they may not change.

-- 
     ,_
     /_)              /| /
    /   i e t e r    / |/ a g e l

Re: [Pyunit-interest] __init__() breaks TestCase subclass

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

Ng Pheng Siong wrote:
> 
> My test case subclass has an __init__(). If I remove it then all is fine.
> 
>     class aClassTestCase(unittest.TestCase):
>         def __init__(self):
>             unittest.TestCase.__init__(self)
>             self.x = 'x'

Hi; the problem is that the __init__ method in TestCase takes a parameter
that is the name of the test method that will be run by the instance.

Therefore, if you override the constructor in subclasses of TestCase, you
should always call the base class constructor with an argument. I'm pretty
sure this is mentioned in the documentation, but I'll make sure.

So, your code should look like this:-

     class aClassTestCase(unittest.TestCase):
         def __init__(self, name='check_something'):
             unittest.TestCase.__init__(self, name)
             self.x = 'x'

Hope that helps.

Best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
"Life must be simple if *I* can do it" -- me

[Pyunit-interest] __init__() breaks TestCase subclass

[Ng P. S. <ng...@po...>]

Hi,

I've seem to have run into a bug: 

    /usr/local/home/ngps/prog/pyunit:$ ./test.py 
    Traceback (most recent call last):
      File "./test.py", line 31, in ?
        unittest.TextTestRunner().run(suite())
      File "./test.py", line 27, in suite
        return unittest.makeSuite(aClassTestCase, 'check')
      File "/usr/local/lib/python2.0/site-packages/unittest.py", 
        line 391, in makeSuite
        getTestCaseNames(testCaseClass, prefix, sortUsing))
    TypeError: too many arguments; expected 1, got 2


My test case subclass has an __init__(). If I remove it then all is fine.

    /usr/local/home/ngps/prog/pyunit:$ cat test.py 
    #!/usr/bin/env python
    
    import unittest
    
    class aClass:
        def __init__(self, qn, ans):
            self.qn = qn
            self.ans = ans
    
    class aClassTestCase(unittest.TestCase):
    
        def __init__(self):
            unittest.TestCase.__init__(self)
            self.x = 'x'
    
        def setUp(self):
            self.obj = aClass('the meaning of life', 42)
    
        def tearDown(self):
            pass
    
        def check_something(self):
            assert self.obj.ans == 42
    
    
    def suite():
        return unittest.makeSuite(aClassTestCase, 'check')
        
    
    if __name__ == '__main__':
        unittest.TextTestRunner().run(suite())
    

Hints on getting around this appreciated. Cheers.

-- 
Ng Pheng Siong <ng...@po...> * http://www.post1.com/home/ngps

Re: [Pyunit-interest] code coverage module?

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

Thomas Heller wrote:
> > Recently I received a mail from Greg Wilson (of SoftwareCarpentry fame)
> > because he is interested in helping me to integrate a pre-existing code
> > coverage library called 'PyCov' into PyUnit.
> Do you have any pointer to this code?
> 

Yes, after some digging I found the following URL:

   http://www.geocities.com/SiliconValley/Peaks/7506/pycover-0_2.tgz

The author is Drew Csillag.

-Steve

-- 
Steve Purcell, Pythangelist
"Life must be simple if *I* can do it" -- me

Re: [Pyunit-interest] code coverage module?

[Thomas H. <tho...@io...>]

> Recently I received a mail from Greg Wilson (of SoftwareCarpentry fame)
> because he is interested in helping me to integrate a pre-existing code
> coverage library called 'PyCov' into PyUnit.
Do you have any pointer to this code?

Thomas

Re: [Pyunit-interest] code coverage module?

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

Thomas Heller wrote:
> Dear unit-testers,
> 
> Recently there has been an announcement on c.l.p
> for amk's quixote library, which also contains a unit
> testing framework. While I like pyunit more than
> amk's version, he included a code coverage tool
> (written by Skip Montanaro, Andrew Dalke, and
> Neil Schemenauer).
> 
> Do you think it is a good idea to include
> this module also in pyunit, or is code coverage
> too far away from unit-testing?

Hi Thomas and others,

I read the announcement with interest, but have not looked at AMK's module
yet due to lack of time.

Recently I received a mail from Greg Wilson (of SoftwareCarpentry fame)
because he is interested in helping me to integrate a pre-existing code
coverage library called 'PyCov' into PyUnit. I am in favour of such an
integration, but again have not yet had time to investigate further. Perhaps
Quixote's bundled coverage module is the same one?

I would welcome any help or suggestions for such work.

Best wishes to all,

-Steve

-- 
Steve Purcell, Pythangelist
"Life must be simple if *I* can do it" -- me

[Pyunit-interest] code coverage module?

[Thomas H. <tho...@io...>]

Dear unit-testers,

Recently there has been an announcement on c.l.p
for amk's quixote library, which also contains a unit
testing framework. While I like pyunit more than
amk's version, he included a code coverage tool
(written by Skip Montanaro, Andrew Dalke, and
Neil Schemenauer).

Do you think it is a good idea to include
this module also in pyunit, or is code coverage
too far away from unit-testing?

Cheers,

Thomas 

[Pyunit-interest] Re: JPython testing framework

[Tjitske H. en O. P. <th...@nl...>]

James & others,

I just found out that the Python traceback.py module also works with
JPython! Simply copy traceback, stat, linecache from a Python installation
(I used version 1.6) and PyUnit works with almost no changes. I only had to
fix the "import" thing in the createTestInstance.

-Otto

----- Original Message -----
From: <he...@ho...>
To: <th...@nl...>; <jpy...@py...>;
<PL...@op...>; <Alo...@op...>
Sent: Tuesday, October 03, 2000 11:36 PM
Subject: Re: JPython testing framework


> Hello all,
>
> Well, as Otto as indicated, converting PyUnit to run with JPython seems to
> be a pretty painless exercise.  I've added the modified version of
> unittest.py that I just put together.  Seems to work OK, although I
haven't
> used it extensively so I make no guarantees ;)...
>
> James

Re: [Pyunit-interest] Using PyUnit with JPython to test-drive Java?

[Tjitske H. en O. P. <th...@nl...>]

Steve,

Thanks for the hint. I've modified the unittest.py a little and it now works
with JPython (text-only, but that's okay).
Only remaining problem is the stacktrace for failures: it currently only
shows the calls to
unittest.py methods, not the call in the actual test routine or a trace
through the Java sources
that I'm testing. The problem was with the use of the "traceback" module in
printNumberedErrors.
I've modified it and it now looks like this:

    def printNumberedErrors(self,errFlavour,errors):
        if not errors: return
        if len(errors) == 1:
            self.stream.writeln("There was 1 %s:" % errFlavour)
        else:
            self.stream.writeln("There were %i %ss:" %
                                (len(errors), errFlavour))
        i = 1
        for test,error in errors:
            self.stream.writeln("%i) %s" % (i, test))
# changes start here
#            errString =
string.join(apply(traceback.format_exception,error),"")
#            self.stream.writeln(errString)
            errclass,errmsg,errstack = error
            errstackdump = java.lang.StringBuffer()
            errstack.dumpStack(errstackdump)
            self.stream.writeln("%s %s" % (errclass,errmsg))
            self.stream.writeln("%s" % errstackdump)
# end changes
            i = i + 1

But this is not yet perfect. Anyone a better solution here?

Anyway, using JPython with PyUnit to test-drive Java is a much better
solution than
using JPython with JUnit.

-Otto Perdeck

> > [snip] I would prefer to use PyUnit to drive my Java classes.
> > In the doc it is suggested that this isn't possible, but why is that?
[snip]
>
> There are a few complications; I think they were mainly covered in a few
mails
> on this list a couple of months back. If you didn't already look, perhaps
> you could look at the list archives and see if they answer your questions.

> The interrelationship of JUnit and PyUnit together with JPython/CPython is
> one of great interest to me. I have to admit that I'm currently doing Java
> work with JUnit, and I'm writing the tests in Java.
>
> I'm trying to pick out aspects of JUnit v3 that might be useful in PyUnit,
but
> usually I prefer to keep things simple so that my poor brain can
understand
> them.
> Steve Purcell, Pythangelist

Re: [Pyunit-interest] Using PyUnit with JPython to test-drive Java?

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

Hi Otto,

> [snip] I prefer to use a scripting language such a JPython instead
> of writing all the tests in Java itself.

Then you're a very smart guy! :-)

> [snip] I would prefer to use PyUnit to drive my Java classes. 
> In the doc it is suggested that this isn't possible, but why is that? [snip]

There are a few complications; I think they were mainly covered in a few mails
on this list a couple of months back. If you didn't already look, perhaps
you could look at the list archives and see if they answer your questions.

The interrelationship of JUnit and PyUnit together with JPython/CPython is
one of great interest to me. I have to admit that I'm currently doing Java
work with JUnit, and I'm writing the tests in Java.

I'm trying to pick out aspects of JUnit v3 that might be useful in PyUnit, but
usually I prefer to keep things simple so that my poor brain can understand
them.

Looking forward to any unanswered questions you may have,

Best wishes,

-- 
Steve Purcell, Pythangelist
"Life must be simple if *I* can do it" -- me

[Pyunit-interest] Using PyUnit with JPython to test-drive Java?

[Tjitske H. <th...@nl...>]

I'm currently using JPython to write unit-tests for a large Java =
application. I prefer to use a scripting language such a JPython instead =
of writing all the tests in Java itself.

This works, but the cooperation between the scripts JPython and JUnit is =
not perfect (e.g. exception handling). I would prefer to use PyUnit to =
drive my Java classes.=20

In the doc it is suggested that this isn't possible, but why is that? =
Has anyone found any workarounds for this? I found myself creating a =
TestUnit subclass in JPython of the JUnit TestUnit Java class that =
improves things a little, but probably someone else has been there =
already...

- Otto Perdeck

Re: [Pyunit-interest] passing arguments to TestCase constructor through makeSuite

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

Andrew Wilcox wrote:
> In my application, I'm passing some contextual information into my TestCase
> constructor with a couple of extra arguments.  (I'm using Zope, and the
> request information is passed in to me as an argument).  This is easy
> enough to do, but the makeSuite function only calls the constructor with
> the method name.

Hi Andrew,

Thanks for sharing this.

Your example illustrates the complication of testing inside a server
environment, where the tests are dependent upon the environment. I'd love to
hear more about how you're tackling this.

I'm having a lot of the same issues currently, but with the Java and JUnit in
the Enhydra application server. My take on things is the following:

Usually every TestCase should be instantiable and runnable in its own right,
given the right environment, and so it is not recommended to pass in context
information. The test case should create its own context in the setUp method.

In server environments such as Zope, this often means artificially creating
requests from within the test case. A TestRunner subclass customised to the
server is often written, and its task of running of tests inside the
environment is triggered by a request from outside the server process, e.g. by
http. In the case of Zope, this might mean writing a TestRunnerProduct or
suchlike. I think there's some information on Zope.org about using PyUnit
with Zope, though I don't know how much detail there is.

Best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
"Life must be simple if *I* can do it" -- me

[Pyunit-interest] passing arguments to TestCase constructor through makeSuite

[Andrew W. <ci...@gw...>]

In my application, I'm passing some contextual information into my TestCase
constructor with a couple of extra arguments.  (I'm using Zope, and the
request information is passed in to me as an argument).  This is easy
enough to do, but the makeSuite function only calls the constructor with
the method name.  Here is my extension to makeSuite() that I'm using to
allow me to pass through my necessary extra arguments.


def makeSuite(testCaseClass, prefix='test', sortUsing=cmp, arguments=()):
    """Returns a TestSuite instance built from all of the test functions
       in the given test case class whose names begin with the given
       prefix. The cases are sorted by their function names
       using the supplied comparison function, which defaults to 'cmp'.

       The test case class constructor is called with the method name,
       and any extra arguments passed in 'arguments'.
    """
    cases = map(lambda methodName, testCaseClass=testCaseClass,
arguments=arguments:
                apply(testCaseClass, (methodName,) + arguments),
                getTestCaseNames(testCaseClass, prefix, sortUsing))
    return TestSuite(cases)

[Pyunit-interest] Patch: more extensible PyUnit base classes

[Pieter N. <pn...@tb...>]

I extended TextTestRunner into a test harness suitable for use under
Aegis[1], and in the process I needed to make the base classes more
extensible.

One problem is gratuitous underscore-privitization of names, i.e. I
would really like to get at TestSuite's _test member in subclasses.

I also think the object factory aproach of
TestCase.defaultTestResult() should be extended to the TestRunner
class, so that subclasses can decide to use appropriate TestResult
subclasses.

Here is a patch towards that. It also adds one fun change: if the
test methods have doc strings, they also appear in the Test's string
representation. That way one can do things like:

class FrobTest(TestCase):
    def checkSnazzle(self):
        """Does the Frob tweak its snazzle after reset?"""
	self.frob.reset()
	assert self.frob.snazzle

and have that textual comment of what is wrong when the test fails
appear as part of the result.


[1] Aegis  http://www.canb.auug.org.au/~millerp/aegis/ is a great GPL
revision control/CASE/process management tool which enforces unit
testing before any changes are committed to the baseline. Aegis,
Python and PyUnit will compliment each other very nicely as soon as
some problems are sorted out in the next Aegis release.

The test-infected community of this list might want to take a look at
it. Steve will be pleased to hear that I submitted an Aegis/Python
howto to the author which recommends PyUnit.

-- 
     ,_
     /_)              /| /
    /   i e t e r    / |/ a g e l

[Pyunit-interest] New wxGui

[Nathan H. <bak...@he...>]

I've attached the new version of my (unofficial) pyunit gui. The new
feature is a combobox that lists all the "testable" .py files in the
current dir. It uses a simple file name match to determine if the file
is testable. The pattern I use it "Test.py$" and is easily modified.

If anyone is interested I can make the pattern more easily modified.
Also, upon interest I can make another shortcut: while the current
version assumes you want to run getSuite(ModuleName.ModuleName) to get
your suite, I've been thinking of trying ModuleName.suite. If there is a
way you work that I don't and you actually use this Gui, I'll modify it.

Also, the cool-idea project weblib seems to be using Steve's unit
testing framework. Cool.

-- 
Nathan Heagy
------------
A Dead Cow is a Funny Cow
- http://cowcomics.com/ -

[Pyunit-interest] Notes concerning forcing module reloads

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

I had some fun getting PyUnit to reliably reload modules before each test
run. I wrote up some notes about what I discovered along the way, in case
anyone is interested:

  http://pyunit.sourceforge.net/notes/reloading.html

-Steve

-- 
Steve Purcell,  Technical Director, Inkontact
Get in touch at http://www.inkontact.com/
"Life must be simple if I can do it" -- Me

[Pyunit-interest] Using PyUnit GUI from PythonWin

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

Windows users,

Please note that you will probably have problems running the PyUnit GUI from
the PythonWin IDE -- this is due to bugs in PythonWin that prevent it from
co-existing happily with Tkinter. The solution is to run 'unittestgui.py'
using the standard 'python.exe' or 'pythonw.exe', or by double-clicking on
the 'unittestgui.py' file in Explorer.

I've tried this successfully on Windows 98, with Python 1.5.2.

-Steve

-- 
Steve Purcell,  Technical Director, Inkontact
Get in touch at http://www.inkontact.com/
"Life must be simple if I can do it" -- Me

[Pyunit-interest] Idea of 'suite' method in TestCase

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

Hi again,

A few people have suggested the addition of a 'suite' factory method
to the TestCase class. Now, at the weekend I also decided that this might
be a nice idea. I figured out why it's not so easy to do, though.

What is really wanted is a 'static' method in TestCase, to use Java's
terminology:

 class MyTestCase(unittest.TestCase):
    def suite(): return unittest.makeSuite(MyTestCase)

Then, a suite could be obtained using 'MyTestCase.suite()'.

Of course, this doesn't work because 'suite' can only be called on an
instance of the class, and we don't want to have to create a TestCase just
to call its 'suite' method and then dump it.

I tend to just create outboard TestSuite subclasses or factory functions
named after the associated TestCase, i.e. TrampolineTestSuite for
TrampolineTestCase.

But how about:

 class MyTestCase(unittest.TestCase):
    class suite(unittest.TestSuite):
       def __init__(self):
         unittest.TestSuite.__init__(self,(unittest.makeSuite(MyTestCase),))
    ...

or even:

 class StaticMethod:
   def __init__(self, func, *args, **kwargs):
     self.func = func
     self.args = args
     self.kwargs = kwargs
   def __call__(self):
     return apply(self.func, self.args, self.kwargs)

 class MyTestCase(unittest.TestCase):
   ...

 MyTestCase.suite = StaticMethod(unittest.makeSuite, MyTestCase)


Not particularly nice, I admit, but it you want a suite for each TestCase,
one of these ideas might help you.

Incidentally, if you use the first code snippet above then subclass your
TestCases from 'MyTestCase' rather than 'TestCase', you will then have a
'suite' pseudo-method in each of your subclasses.

I don't think I advocate this, so I'm probably just corrupting your sensible
minds and causing trouble. Again. :-)

Best wishes to all,

-Steve

-- 
Steve Purcell,  Technical Director, Inkontact
Get in touch at http://www.inkontact.com/
"Life must be simple if I can do it" -- Me

[Pyunit-interest] New release: 1.2.0, featuring GUI test runner

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

Folks,

The latest PyUnit release is out, featuring a Tkinter-based GUI test runner.

I would really appreciate feedback so that I can turn around any necessary
fixes as quickly as possible.

As always, everything can be found at http://pyunit.sourceforge.net/

Best wishes to all,

-Steve

-- 
Steve Purcell,  Technical Director, Inkontact
Get in touch at http://www.inkontact.com/

[Pyunit-interest] Using JPython with JUnit

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

As a follow-up to Rob's enquiries about using PyUnit with JPython, I had a
bit of a play around. I tried writing a JUnit test case using JPython; in
case anyone is interested, some sample code is shown below. It's a little
clunky.

I can see some arguments in favour of making PyUnit work with JPython
(at least with the TextTestRunner), so I'll probably plan to roll those
changes into the next release.

#----------------------------------------------------
import sys
sys.add_package('test.framework')
sys.add_package('test.textui')
import test.framework
import test.textui
  
class MyTestCase(test.framework.TestCase):
   def __init__(self):
      test.framework.TestCase.__init__(self,"MyTestCase")
   def runTest(self):
      a = 1
      # etc                                                                    
      # assert a == 2
  
if __name__ == '__main__':
   testcase = MyTestCase()
   test.textui.TestRunner.run(testcase)
#---------------------------------------------------- 

-- 
Steve Purcell,  Technical Director, Inkontact
Get in touch at http://www.inkontact.com/

Re: [Pyunit-interest] JPython compat

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

Rob Giardina wrote:
> Does anyone have a pointer on the incompatibility with JPython? The doc
> expressly says it's not compatible...

Hi Rob,

I didn't make any great effort to make PyUnit run identically in CPython and
JPython for a few reasons.

Firstly, there's already JUnit, and its TestCase class can be directly
subclassed in JPython. Why reinvent the wheel, I thought?

Secondly, any future GUI test runner for PyUnit would not work with JPython,
since it would most probably use Tkinter. And since JPython subclasses of
PyUnit's TestCase class don't work with JUnit, PyUnit would end up needing
its own JPython clone of JUnit's GUI. Doesn't sound like the Simplest Thing
That Could Possibly Work.

Thirdly, I've found JPython disappointing, and most efforts to make
non-trivial code work identically in CPython and JPython end up in a big mess.
Although I use JPython quite a lot, I restrict its use to those situations
in which I know it works, and I use the old JPython rather than the new one
because it feels more solid.

Technically, the reason for the current incompatibility is that for
readability of error printouts, I tweak the traceback object a little.
JPython's traceback objects are different to those of CPython, so that
code will not work with JPython.

Now...

I hear that with a few changes in 'unittest.py', PyUnit in its current
incarnation *does* work with JPython. So, if text output only is okay, I
would be happy to share the secret incantations!

I'd love to hear about how well (or not) subclassing JUnit's UnitTest works
with JPython, too.

Best wishes,

-Steve P.

-- 
Steve Purcell,  Technical Director, Inkontact
Get in touch at http://www.inkontact.com/

[Pyunit-interest] JPython compat

[Rob G. <rg...@ho...>]

Does anyone have a pointer on the incompatibility with JPython? The doc
expressly says it's not compatible...

Thanks.

Rob Giardina
CriticalPoint Software
-----------------(*)-----------
ro...@cr...

Re: [Pyunit-interest] New wxGui version

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

Nathan Heagy wrote:
> 
> However, I *cannot* get nested suites to run. Can someone please send me
> a working example of nested suites? 

Check out 'alltests.py' in the examples directory of the pyunit distrib.

-Steve

-- 
Steve Purcell,  Technical Director, Inkontact
Get in touch at http://www.inkontact.com/

[Pyunit-interest] New wxGui version

[Nathan H. <na...@he...>]

I've made a new version of my PyUnit gui. It's still based on wxWindows,
and is still 100% guaraunteed to reload ALL relevant modules each time a
test is run.

The major change in this version is that it is now fully compatible with
unittest.py 1.1.0 as supplied by Steve. I have tested out the syntax
compatibility with Steve's TextTestRunner and it seems OK. 

However, I *cannot* get nested suites to run. Can someone please send me
a working example of nested suites? 

The gui is attached as wxTestRunner.py.
-- 
Nathan Heagy
------------
Blow Your Beef Away
http://cowcomics.com

Re: [Pyunit-interest] Assert Equals

[Michal W. <sa...@ma...>]

On Sat, 10 Jun 2000, Nathan Heagy wrote:

> I've been playing with other language's testing frameworks (based on
> junit) and I really like the assertequals functions. This the expected
> and received values on error. In php this is done similar to
> 
> this.assertequals(value_one, value_two)
> 
> also, php does not use the built-in assert, it uses a 
> 
> this.assert(value_one > value_two)
> 
> Is there any interest to implementing either of these in PyUnit? I'm
> interested in both, and will probably add atleast assertequals to my own
> copy. 

Hey Nathan,

It seems to me that the built-in python syntax is actually more concise:

>>> assert value_one == value_two

and:

>>> assert value_one > value_two

.. Plus you can add a helpful message:

>>> assert value_one > value_two, "value_one should have been > than value_two"


Is that not what you want?

Cheers,

- Michal
------------------------------------------------------------------------
Zike Interactive    http://www.zike.net/    http://zike.sourceforge.net/
------------------------------------------------------------------------