pyunit-interest

[Pyunit-interest] Using re to describe test methods to test

[Dinu G. <gh...@da...>]

Hello,

while developping test suites I found myself quite often
writing code like this:

    suite.addTest(TestClassA('test1'))
    suite.addTest(TestClassA('test2'))

    suite.addTest(TestClassB('test1'))
    suite.addTest(TestClassB('test2'))

    suite.addTest(TestClassC('test1'))
    suite.addTest(TestClassC('test2'))
    suite.addTest(TestClassC('test3'))

Because I was spending an increasing amount of time editing 
the list above, commenting lines and uncommenting them again,
one day I began using regular expressions to describe what 
methods I really wanted tested and found this to save quite 
some time again.

I've attached a module showing in full action what I mean, 
working partly on itself as a test case. In fact, I have 
tried to bind the getTestMethodNames function to some test
classes as a class method, but found that to be conflicting
either with the unittest module or my brain, so I dropped
that again (but it's not really necessary to do that any-
way).

I'm not sure if this is also useful for other folks here,
but in any case you may give it a try and/or Steve might
want to think about if or not it would make sense to add
something like this to the package itself. In that case
it might look like this, perhaps:

    suite.addTests(TestClassC('test\d+'))

Regards,

Dinu

-- 
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or 
not. Otherwise you don't enjoy your work, you don't work well, 
and the project goes down the drain." 
                    (Kent Beck, "Extreme Programming Explained")

[Pyunit-interest] PyUnit in Python 2.1 standard library

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

Hi everyone,

PyUnit just got checked into the Python 2.1 standard library, and should
make the Python 2.1b2 release! I hope this turns out to the all-round
Good Thing that I think it is. 

Many thanks to Fred Drake for helping to make this happen! Fred has
already put a couple of PyUnit-based tests into the Python regression
test suite. (e.g. test/test_fnmatch.py)

Thanks also to all of you who've used and endorsed PyUnit, and sent
suggestions and patches to me!

If *you* are able to try running your existing PyUnit tests using this new
standard library version of 'unittest.py', please can you do so and let me know
how you get on!

Note that 'unittestgui.py' is *not* in the python standard library; it may
be distributed in 'Tools' or separately.

Ongoing PyUnit development will continue on the PyUnit site, and changes
will be coordinated between the standard library version and the independently
distributed version. The independent version will be mainly for users
of pre-2.1 Pythons (myself included, for a little while at least). 

The only significant change envisioned is an addition of support for code
coverage measurement. (I want to make sure that is done without breaking
compatibility with Jython.)

I'd like to see some development of testing GUIs start now; integration
with one or more of the prevalent Python IDEs would be great.

Best wishes to all,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Any opinions expressed herein are my own and not necessarily those of Yahoo

Re: [Pyunit-interest] is this the right place?

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

Sebastian Ahrens wrote:
> ----snip---- 
>  would highly recommend that you join the mailing list provided at 
> pyunit.sourceforge.net and forward this dicussion to that list.
> ----snip---- 
> Now as you can see Bill told me to ask you folks on the pyunit 
> mailinglist, but before I go on asking questions concerning the  
> python/obj-c binding give a hint whether this is the right place here 
> ----snip---- 

This is the perfect place to discuss unit testing, but not the
python/obj-c binding; it sounds like you want to discuss the latter, but
I can't tell from the snippets you forwarded.

Best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Any opinions expressed herein are my own and not necessarily those of Yahoo

Re: [Pyunit-interest] is this the right place?

[Bill B. <bb...@co...>]

No, it isn't... sorry about that.

Should be pyobjc@sourceforge.

Between Python 2.1, OSX, WO 5.0, pyunit, pyobjc, and several other 
internal projects, my brain has fused and is crossing signals.

b.bum

On Wednesday, March 21, 2001, at 12:49 PM, Sebastian Ahrens wrote:

> Bill Bumgarner wrote:
>
> I generally run a python script that instantiates some python objects
> and passes them off to ObjC.  Then, from ObjC one can transparently
> message the Python objects.  It would be trivial instantiate an instance
> of one of the various python interpreter controller objects (can't
> remember the module at the moment) and pass that off to ObjC.  That
> would give you an ObjC interface to the Python interpreter
>
> ----snip----
>
>  would highly recommend that you join the mailing list provided at
> pyunit.sourceforge.net and forward this dicussion to that list.  I don't
> have the time at the moment to be as active with the development of
> PyObjC as I would like.   That may change in the near future, but likely
> not.  However, there are a number of folks in the community that are
> very active and would appreciate your input!
>
> Now as you can see Bill told me to ask you folks on the pyunit 
> mailinglist, but before I go on asking questions concerning the
> python/obj-c binding give a hint whether this is the right place here
>
>
> best regards
> -------------------------------------------------------
> Sebastian Ahrens
> SmartCards, Digital Signature and XML
> Genius Bytes Software Solutions GmbH
> ah...@ge...
>  _______________________________________________ Pyunit-interest 
> mailing list Pyu...@li... 
> http://lists.sourceforge.net/lists/listinfo/pyunit-interest

[Pyunit-interest] is this the right place?

[Sebastian A. <ah...@ge...>]

<=
flushleft><fontfamily><param>Helvetica</param><x-tabstops><param>28L;56L;8=
4L;112L;140L;168L;196L;224L;252L;280L;308L;336L;</param>Bill Bumgarner =
wrote:

<italic>

I generally run a python script that instantiates some python =
objects</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>and passes them off to ObjC.  Then, =
from ObjC one can =
transparently</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>message the Python objects.  It would =
be trivial instantiate an =
instance</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>of one of the various python =
interpreter controller objects =
(can't</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>remember the module at the moment) and =
pass that off to ObjC.  =
That</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>would give you an ObjC interface to the =
Python interpreter


----snip----


 would highly recommend that you join the mailing list provided =
at</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>pyunit.sourceforge.net and forward this =
dicussion to that list.  I =
don't</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>have the time at the moment to be as =
active with the development =
of</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>PyObjC as I would like.   That may =
change in the near future, but =
likely</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>not.  However, there are a number of =
folks in the community that =
are</italic><color><param>0000,0000,0000</param>

<italic></italic></color><italic>very active and would appreciate your =
input!</italic><color><param>0000,0000,0000</param>


Now as you can see Bill told me to ask you folks on the pyunit =
mailinglist, but before I go on asking questions concerning the=20

python/obj-c binding give a hint whether this is the right place here



best regards</color>

=
<x-tabstops><param>72L;144L;216L;288L;360L;</param>-----------------------=
--------------------------------

Sebastian Ahrens

SmartCards, Digital Signature and XML

Genius Bytes Software Solutions GmbH

ah...@ge...

</x-tabstops></x-tabstops></fontfamily></flushleft>=

Re: [Pyunit-interest] Verbose idea

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

Chuck Esterbrook wrote:
> Most of the time I run my test suites, I don't want to see any output other 
> than each of the test names. However, when I'm having a problem, I would 
> like to see more diagnostic output on what the test case is doing.
> 
> Here's an idea: If a verbose flag was turned on via the command line (and 
> on through TestSuite and TestCase), then I would get the extra output. 


The CVS version has this functionality, and it will be in the next release.
Fred Drake talked me into adding it a while ago.

So in the next release you can expect that the default output is '.', 'E' or
'F' for each test, followed by a summary of any errors. With a '-q' (quiet)
command-line flag, only the errors will be printed, and with a '-v' (verbose)
flag, the output will be as it is in 1.3.1.

I'll be removing the JUnitTextTestRunner in the next release, because this
configurability of output levels obsoletes it.

If anyone cares to look at the CVS version, comments would be gratefully
received. There have been several changes, the most interesting of which is
that 'unittest.main()', when called without arguments, now locates and runs
all of the tests in the current module.

Best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Any opinions expressed herein are my own and not necessarily those of Yahoo

[Pyunit-interest] Verbose idea

[Chuck E. <ec...@mi...>]

Most of the time I run my test suites, I don't want to see any output other 
than each of the test names. However, when I'm having a problem, I would 
like to see more diagnostic output on what the test case is doing.

Here's an idea: If a verbose flag was turned on via the command line (and 
on through TestSuite and TestCase), then I would get the extra output. 
Something like:

	def checkFoo(self):
		if self.verbose: print 'logging in'
		# blah blah
		if self.verbose: print 'logging out'

More likely I would do this:

	def checkFoo(self):
		v = self.verbose
		if v: print 'logging in'
		# blah blah
		if v: print 'logging out'

Also my print statements are more likely to have some arguments with data 
and so forth.


-Chuck

Re: [Pyunit-interest] stderr vs. stdout

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

Chuck Esterbrook wrote:
> But all the output goes to the console anyway and results.text is 0 bytes 
> in length. A little investigation reveals that VerboseTextTestRunner 
> defaults to sys.stderr:
> 
> def __init__(self, stream=sys.stderr, descriptions=1):
> 
> Is there a reason to default to stderr instead of stdout?

Hi Chuck,

I don't know if it was the wisest decision in the world, but I think I figured
at the time that stderr was the standard stream least likely to conflict
with any output that the tested code might sporadically print.

That is, if the code being tested is sprinkled with 'print' statements 
(god forbid), printing the test results to stderr instead means that you
can get the test results text on a distinct stream.

You should still be able to get the test results into a file by doing:

  ./mytests.py 2>results.log

(at least on UNIX).

You might also consider:

  if __name__ == '__main__':
      runner = unittest.TextTestRunner(sys.stdout)
      unittest.main(defaultTest='suite', testRunner=runner)

Hope that helps.

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Get servlets at http://pyserv.sourceforge.net/
"Even snakes are afraid of snakes." -- Steven Wright

[Pyunit-interest] stderr vs. stdout

[Chuck E. <ec...@mi...>]

On a Windows ME machine, I do this:

python Test.py > results.text


But all the output goes to the console anyway and results.text is 0 bytes 
in length. A little investigation reveals that VerboseTextTestRunner 
defaults to sys.stderr:

def __init__(self, stream=sys.stderr, descriptions=1):


Is there a reason to default to stderr instead of stdout?


-Chuck

[Pyunit-interest] Re: Running tests in parallel

[Bill B. <bb...@co...>]

Finally had a chance to look closely at this.

While it solves on problem-- running a bunch of test cases in parrallel-- I  
also need to be able to run the whole suite in parallel....  any particular  
reason why something similar couldn't be applied to the TestSuite object?

thanks,
b.bum

[Pyunit-interest] Running tests in parallel

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

Bill Bumgarner wrote:
> Finally, I want to be able to run multiple test suites simultaneously
> within a  single Python VM.   In particular, it is often the case that the
> only  effective way to test an application for, say, threading issues or
> other multiuser related issues is to run the app through its paces from
> multiple clients simultaneously.

The following vaguely hacky code might help:

class ParallelTestSuite(unittest.TestSuite):
    """Runs its tests in parallel threads"""
    def __call__(self, testResult):
        from threading import Thread
        threads = []
        for test in self._tests:
            result = test.defaultTestResult()
            thread = Thread(target=test, args=(result,))
            threads.append((test, thread, result))
            thread.start()
        for test, thread, result in threads:
            thread.join()
            testResult.startTest(test)
            for error in result.errors:
                apply(testResult.addError, error)
            for failure in result.failures:
                apply(testResult.addFailure, failure)
            testResult.stopTest(test)


(Most test result classes aren't thread safe, hence the complication of
 the above)

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Get servlets at http://pyserv.sourceforge.net/
"Even snakes are afraid of snakes." -- Steven Wright

Re: [Pyunit-interest] intro & Questions

[Bill B. <bb...@co...>]

Ok-- after several on-list and off-list responses and a bunch more thinking, I  
think I can paint a clearer picture of the problem I'm having with maintaining  
state.

In particular, testing a modern web based application involves both  
maintaining state between request/responses AND possible branching of  
execution/testing.

Example;  I want to write a test that tests the sequence of events that  
involve checking out of an ecommerce store.   There are typically two distinct  
paths to take-- as a registered user and as an unregistered user-- that have a  
tremendous number of steps in common.  As such, it would be useful to be able  
to test, say, the address-entry->credit-card-entry->order-confirmation sequence  
of pages as a single TestCase with two OTHER test cases that test new-user vs.  
registered-user functionality.   Pick one of new-user, registered-user... go  
through test cases... hand control to the address/cc/order-confirmation test.

However, this requires the preservation of a minimal amount of state between  
tests;  i.e. I need to keep around the state resulting from the last response  
generated by the registered user or new user path to pass into the  
address/cc/order-confirmation test as the foundation of state for that test.

I understand that this violates the idea that TestCases should each start with  
a clean slate.   However, I also firmly believe that there are numerous  
situations within which starting from a clean slate is not really testing the  
system.

Finally, I want to be able to run multiple test suites simultaneously within a  
single Python VM.   In particular, it is often the case that the only  
effective way to test an application for, say, threading issues or other  
multiuser related issues is to run the app through its paces from multiple  
clients simultaneously.

b.bum

[Pyunit-interest] PyUnit integration into Python 2.1

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

All,

As some of you may be aware, it appears to have been decided that PyUnit's
'unittest' module will be adopted into the standard Python 2.1 library.

I think this is a great idea for existing users like yourselves, at least when
2.1 becomes the version you typically use. (For me personally, that is some
time away.)

There are likely to be a few changes during that adoption process: I will
be trying my best to make sure that nothing happens to break existing tests.

If there are any comments, suggestions or questions related to this process,
please mail me or the list.

I will continue to maintain (and probably further develop) PyUnit indefinitely
while there are older Python versions in widespread use.

Best wishes to all,

-Steve

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

[Pyunit-interest] New minor release: 1.3.1

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

There was a small bug in the JUnitTextTestRunner, which I'd left in PyUnit
for the benefit of those who might not like the new text output format. Thanks
to those who pointed out the bug.

The bug is fixed in the new release 1.3.1.

Also, Jim Fulton proposed a 'debug' method for TestCases and TestSuites
which allows running the tests from a debugger or the interactive Python
prompt without exceptions being automatically collected for later reporting;
this change is also in the new release.

As usual: http://pyunit.sourceforge.net/

Sorry to have you guys running around fetching a new release again so soon.

Best wishes,

-Steve

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

Re: [Pyunit-interest] intro & Questions

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

Bill Bumgarner wrote:
> 	While it is trivial to use PyUnit to trigger, say, JUnit  
> based tests internal to the application or applications, that doesn't  
> provide the level of testing that I need.  In particular, it doesn't  
> test user level interaction with the site via HTTP.
> [snip]
> 	- PyUnit doesn't seem to maintain state between test runs.   
> I.e. if I have a TestCase subclass with 10 test cases, that results  
> in 10 individual instances of the TestCase subclass.

Yep, this is intentional, because tests should not interfere with each other.

> However, I need  
> to maintain state across tests-- session identifiers and the other  
> wonderful fallout from apps deployed against the web.   I can't  
> imagine this is a new problem and, while my solution works, I'm  
> curious what others have done and if there is some kind of a  
> "standard" pattern.

You're right -- this isn't a new problem.

I recently had to solve the same thing in my day job, and I came up with a
fun solution that really works nicely.

I wrote a module 'httpsession' that simulates a browser session with a
remote HTTP server. It tracks and sends cookies, follows redirects, allows
posting of forms and can be inspected after each page request to ensure
that the session is in the required state. Here's a sample test:

class LoginTestCase(unittest.TestCase):
    ...

    def makeSession(self):
        return httpsession.HTTPSession(baseURL=self.fullURL('/'))

    def testLoginRequired(self):
        session = self.makeSession()
        session.get("/", redirectsAllowed=2)
        assert session.replycode == 200
        assert session.path == self.LOGIN_PAGE
        assert session.query['redirect'] == self.MENU_PAGE


Now, the steps required to perform a log-in could be put in the 'setUp'
method of such a TestCase class:

class PostLoginTestCase(unittest.TestCase):

    def setUp(self):
        self.session = self.makeLoggedInSession()

    def makeLoggedInSession(self):
        session = httpsession.HTTPSession(baseURL=self.fullURL('/'))
        session.get("/Login", {'login':'myuser', 'password':'mypassword'})
        assert session.path == self.MENU_PAGE
        return session

    def testManagementPageVisible(self):                   
        self.session.get(self.MANAGEMENT_PAGE)
        assert session.replycode == 200
        assert session.path == self.MANAGEMENT_PAGE


Then any test methods, such as 'testManagementPageVisible' can assume that
self.session is a validly logged-in session.

This way, a very complete test suite can be built up, but every test case
starts with a fresh browser session.

Works well for me.

In fact, I've just registered a new 'webunit' project on sourceforge to house
the 'httpsession' module and future additional modules and documentation
related to this style of testing. Nothing there yet, though, so if anyone
wants the current (very imperfect) version of the 'httpsession' module, I'm
happy to send it by mail or post it somewhere.


> 	- What are people doing to automate the run of tests?  If I  
> have a bunch of different python scripts in a directory-- each  
> implementing a test suite-- what is the best way to run everything in  
> the directory?

Take a look at 'examples/alltests.py' in the distribution package. You can
probably figure out a cleverer way, but it depends on how a particular
project arranges its test modules.

> 	- The examples didn't really cover spewing stuff to  
> stdout/stderr during the run.   I don't forsee any particularly nasty  
> problems in doing so, but-- again-- am looking to a more experienced  
> community to provide some guidance.

Try to avoid printing anything while your test runs. If you can't avoid it,
try writing the test output to a file:

    if __name__ == '__main__':
        resultsfile = open('results.log','w')
        unittest.main('suite', testRunner=unittest.TextTestRunner(resultsfile))


> 	thanks-- very cool stuff!  It has already saved me hours of  
> potentially very stupid debugging....

Sounds like a good thing.

Best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Get servlets at http://pyserv.sourceforge.net/
"Even snakes are afraid of snakes." -- Steven Wright

[Pyunit-interest] intro & Questions

[Bill B. <bb...@co...>]

Hey!

	My company is in the business of building software systems  
primarily targeted to using HTTP as the deployment "window".  I.e. we  
build web sites that require complex infrastructure / moving parts.   
 As we heavily embrace XP practices and understand the value of  
testing, I have been tasked with building tools to aid in the testing  
of web based software.

	While it is trivial to use PyUnit to trigger, say, JUnit  
based tests internal to the application or applications, that doesn't  
provide the level of testing that I need.  In particular, it doesn't  
test user level interaction with the site via HTTP.

	I have a relativley crude set of tools written against  
PyUnit that allow one to test form interaction or a series of  
request/responses where each request/response requires state from the  
previous r/r.   This raised two questions:

	- PyUnit doesn't seem to maintain state between test runs.   
I.e. if I have a TestCase subclass with 10 test cases, that results  
in 10 individual instances of the TestCase subclass.  However, I need  
to maintain state across tests-- session identifiers and the other  
wonderful fallout from apps deployed against the web.   I can't  
imagine this is a new problem and, while my solution works, I'm  
curious what others have done and if there is some kind of a  
"standard" pattern.

	- What are people doing to automate the run of tests?  If I  
have a bunch of different python scripts in a directory-- each  
implementing a test suite-- what is the best way to run everything in  
the directory?

	- The examples didn't really cover spewing stuff to  
stdout/stderr during the run.   I don't forsee any particularly nasty  
problems in doing so, but-- again-- am looking to a more experienced  
community to provide some guidance.

	Any other suggestions?

	thanks-- very cool stuff!  It has already saved me hours of  
potentially very stupid debugging....

	b.bum

[Pyunit-interest] Some PyUnit snippets

[Joshua Macy/T. P. <Ma...@to...>]

Here are a couple of things that I do all the time, just in case anyone is
interested.  (I think both might be relevant to the current discussion on
the Python Dev in regard to using PyUnit as Python's official unit test
module.)

Syntactic sugar for common tests:

def assertEquals(got, expect, error):
    assert got == expect, '''%s: expected %s, got %s''' % (error, `expect`,
`got`)

Invocation of Tim Peters' doctext module (also becoming part of Python
core):

class DocTestCase(unittest.TestCase):
    def setUp(self):
        """Override setUp in derived classes to set the doctest to the
appropriate doctest object from the module.

        Usually this looks like:
        import doctest, mymodule
        self.doctest = doctest.testmod(mymodule, verbose=0)
        """
        self.doctest = None

    def checkDoc(self):
        if self.doctest:
            errors, tests = self.doctest(0)
            assertEquals(errors, 0,
                         '%s Doctest failed, %s errors out of %s tests' %
(self.__class__.__name__, errors, tests))

It might actually make more sense to override DocTestCase's __init__ to set
self.doctest, since there's no real reason to create a doctest object every
time.  On the other hand, a DocTestCase will almost never have more than
one check method, so performance-wise it's probably moot.


Joshua

[Pyunit-interest] PyUnit 1.3.0 released.

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

Hi all,

I wanted to send a short mail to let you know that a new version of PyUnit
has just been released. From the CHANGES file:

Changes from 1.2.0 to 1.3.0
---------------------------

* Clearer and more verbose text output format
* Tests run in text mode can now be interrupted using ctrl-c
* New FunctionTestCase class provides support for wrapping legacy test
  functions into PyUnit test case instances
* Code is now compatible with JPython (new example: examples/withjpython.py)
* Support for short descriptions of tests, taken from __doc__ strings
  by default
* Updated and expanded documentation
* Tested with Python 2
* Changed module reloading mechanism in GUI test runner to fix a problem
  with Python 2 on Win32 reported by Henrik Weber (bug 125463)
* Convenient new unittest.main() function for use by all test modules

I feel very happy about this new release because it solves a few niggling
issues that have bugged me for a while.

A quick link to the download package is:

   http://download.sourceforge.net/pyunit/pyunit-1.3.0.tar.gz

I hope that if any of you have any problems and/or comments you will let me
know!

Very best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Available for consulting and training.
"Even snakes are afraid of snakes." -- Steven Wright

[Pyunit-interest] PyUnit and Python 2

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

Hi again,

I already had a bug report from Henrik Weber concerning PyUnit with Python 2
on Windows.  Thanks Henrik. :-)

Now, I want to help make sure that PyUnit works perfectly for Python 2 ASAP,
and so...

I'd love to hear from any of you about whether you have already switched from
Python 1.5.x to Python 2, and if not, whether you plan to do so in the near
future. Also, would that be Windows, Unix or "other"?

If you have already switched, have you had problems?

(Personally, I've been holding off on making the change until all the add-on
C-based modules (e.g. PIL) are reliably packaged for the new Python. Some of
you are no doubt more adventurous.)

Feel free to drop me a mail with your thoughts.

I'll be looking to make a new release sometime in the next month or so.

Very best wishes,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Available for consulting and training.
"Even snakes are afraid of snakes." -- Steven Wright

[Pyunit-interest] Debian packages / RPMS

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

Hi folks,

I found out yesterday that PyUnit has been packaged for GNU/Debian Linux by
Jerome Marant -- the package name is 'python-unit' (although it may change
to 'python-pyunit' in future) and it is currently in the 'unstable'
distribution pending a move to 'stable'. So, if you use Debian you might like
to check it out:

	http://packages.debian.org/unstable/interpreters/python-unit.html

If anyone knows of a comparable RPM, maybe they can post its URL here?

Best wishes to all,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Available for consulting and training.
"Even snakes are afraid of snakes." -- Steven Wright

Re: [Pyunit-interest] Looking for a JUnit newsgroup

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

Coralee Jyrkama wrote:
> Are there any newsgroups specific to JUnit?  I'll attach my question in case
> anyone knows about JUnit as well.

You'll find plenty of information about JUnit and pointers to further resources
in the archives of the eGroups ExtremeProgramming group:

  http://www.egroups.com/group/extremeprogramming

In fact, a few groups show up if you search on eGroups for 'junit':

  http://www.egroups.com/search?query=junit

Best wishes,

-Steve

P.S. Why not consider switching to Python? -- then you would already be in the
right place.  :-)

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

[Pyunit-interest] Looking for a JUnit newsgroup

[Coralee J. <cjy...@mi...>]

Are there any newsgroups specific to JUnit?  I'll attach my question in case
anyone knows about JUnit as well.
Thanks,
CJ

Re: [Pyunit-interest] code coverage module?

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

Hi Jeremy,

Thanks for the questions.

Jeremy Hylton wrote:
> I just saw the messages on the October archive about integrating a
> code coverage library with PyUnit.  I'm looking at PyUnit for a couple
> of projects where code coverage of Python and C code would be useful.
> 
> I have a bunch of questions:
> 
> Does the PyCov tool do code coverage for Python or for C?

For Python. When I looked at the source I got the impression it wasn't quite
up to the standard of AMK's 'code_coverage.py', which is based on 'trace.py'.

I'm not aware of any Python tools that can do C code coverage, but presumably
there are C-specific tools for that.

> Do you have a URL for it?  The URL in the archive does not work.

Ah, no. If that URL doesn't work, I'm not sure.

> Have you looked at the trace tool in the Python 2.0 distribution?
> It's the code coverage tool written by Skip Montonaro and Andrew
> Dalke.

Only to the extent that 'code_coverage.py' was based on it. Even as a die-hard
Pythoneer I haven't looked into Python 2 yet because there's no widespread
support for it yet in terms of RPMS and other packages for add-ons like PIL.

(It looks like Guido et al have assumed that everyone will jump immediately
to 2.0 but I think it's going to take a surprisingly long time.)

> Has anything happened since the discussion in October?

Yes. I spent a good few hours investigating the whole code coverage topic and
looking at different ways of collecting coverage information. My conclusion
was that the most accurate way to deduce the 'potentially runnable' set of
lines in a given source file is using the method from 'code_coverage'. I was
a little disheartened because it relies on byte code inspection, and would
therefore not work out of the box with JPython.

I hope sometime soon to take that module and integrate it with the rest of
PyUnit. Even adding code coverage reports in the GUI should not be too tricky.
The difficulty is availability of hacking time due to a full-time project I'm
undertaking now, and a lot of related travelling.

Very best wishes,

-Steve

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

[Pyunit-interest] code coverage module?

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

I just saw the messages on the October archive about integrating a
code coverage library with PyUnit.  I'm looking at PyUnit for a couple
of projects where code coverage of Python and C code would be useful.

I have a bunch of questions:

Does the PyCov tool do code coverage for Python or for C?

Do you have a URL for it?  The URL in the archive does not work.

Have you looked at the trace tool in the Python 2.0 distribution?
It's the code coverage tool written by Skip Montonaro and Andrew
Dalke.

Has anything happened since the discussion in October?

Jeremy

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

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

Pieter Nagel wrote:
> 
> 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".

Isn't that what the 'makeSuite' function does?

The TestCase classes often include a number of different test methods, but
each instance, once created, is responsible for running only *one* of those
methods; hence the parameter. This is the (perhaps less-than-obvious)
distinction made between TestCases and TestSuites.

There are probably other ways to arrange matters, but the current way seems
to work for most people.

From what I've seen, most PyUnit test authors use 'makeSuite' to construct
suites from TestCase subclasses in which they have inserted multiple
'checkXXX' methods.

Your suggestion amounts to putting the 'makeSuite' function inside a TestCase,
which amounts to changing a TestCase into a TestSuite.

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

Presumably the latest version of JUnit is representative of any changes they've
made. PyUnit is pretty much up to date with JUnit as far as I can tell, so
I don't think we're lagging too much.

>   - 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.

This is certainly a danger, but "if it ain't broke, don't fix it" suggests
caution so long as the needs of most people are catered for.

Thanks for taking the time to comment. Perhaps you'd like to submit a few
lines of code to show how you'd like the interface to look?

I'd also love to hear specific suggestions from anyone on the list about
possible improvements, now that you've all been using the package for a while.

Best wishes to all,

-Steve

-- 
Steve Purcell, Pythangelist
Mobile: +44 7811 826 620 (UK)
Mobile: +49 175 694 2537 (DE)
"Life must be simple if *I* can do it" -- me