pyunit-interest

[Pyunit-interest] Assert Equals

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

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. 

Also, the gui is working pretty fine. Any objections to it saving a list
of recently run tests in a user's home directory? I'm also having a
problem with current working dir. In java all that's needed is entries
in $CLASSPATH to point to both the tests dir and the working code dir
(if they differ, as mine always do). Is the python $PYTHONPATH and
acceptable equivilent?
-- 
Nathan Heagy
------------
Blow Your Beef Away
http://cowcomics.com

[Pyunit-interest] New GUI Version

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

Hi all.

I made a new version of the wxPython gui. Here's the new features:

* The modules are guaranteed to be reloaded on every test, all of them.
* As the test is running the numbers of how many test, failures, and
errors have occured will be updated. 

I'm currently working on making the GUI take test names input in the
flexible manner that TextTestRunner does. I'll make it totally
compatible with the unittest.py as Steve had it. That's next. I'd also
like to have the gauge update itself too, but I haven't played with the
code that gets the total number of tests yet. I'm not sure the total
number of tests is available before they are all run...

The module reloading is achieved by creating a new process of the gui
which displays nothing and relays results to the GUI through a pipe. I
know Steve didn't like this way, but well it _is_ working.

I'd be happy if any could test it or make (more) suggestions. It's bad
code, so any patches (if you feel so inclined) are welcome. I've
attached the gui as gui.py.

-- 
Nathan Heagy
------------
Blow Your Beef Away
http://cowcomics.com

Re: [Pyunit-interest] Modifications to PyUnit

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

Nathan Heagy wrote:

> The only other solution I can think of is reloading every module in
> sys.modules. The GUI could keep a list of which it was using, and reload all
> the others. As for chaining errors I think this could be solved by reloading
> the set of modules twice.

will that work if you have chains deeper than two? I don't think so. The
logic of it all isn't totally clear to me, so I may be wrong.

> Indeed. The disadvantage is that it is hard to make the results realtime. Most
> tests take only seconds to run. However a large project that has thousands of
> tests and takes minutes to run would not get any feedback from the cgi until
> all the tests have been run, even if the first failed. Of course there is the
> option of a server side push or even a reload/refresh, both of which I'm quite
> familiar with.

or possibly a tiny java applet that can read from a socket and a
javascript that updates a textarea? maybe that's too much overhead.

PS. I'll play with the Tkinter GUI when I have time, thanks for
releasing it.
-- 
sHae mAtijs eRisson (sH...@wE...) gEnius fOr hIre
   bRing mE fIve sQuirrels aNd nO oNe wIll gEt hUrt
13:00pm up 1 season, 1 squirrel, load average: 1+1j 0.5+2j 0.2+0.5j

Re: [Pyunit-interest] Modifications to PyUnit

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

Nathan Heagy wrote:
> 
> As for chaining errors I think this could be solved by reloading
> the set of modules twice.

Aha, good thinking, Batman! That didn't occur to me.

(Relevant anecdote: I was in a long development meeting just over a year
ago in which a group of us were failing to agree on a one-of-many
choice. Each vote we made was equally divided between the options, much
to the eye-rolling disdain of an extremely smart consultant who was
visiting us at the time. Unable to bear our stupidity, the
aforementioned expert finally left the meeting with an exasperated,
"each person should have two votes!" A minute later the decision was
made and our meeting was over.)

> > The CGI test runner idea is a cool one. Talk about a cross-platform GUI!
> 
> Indeed. The disadvantage is that it is hard to make the results realtime. 

I've written CGIs that have been slow to write out a whole page, and the
pages tended to come back a line at a time. I think it should work just
fine, as long as sys.stdout is repeatedly flushed by the CGI.

-Steve

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

Re: [Pyunit-interest] Modifications to PyUnit

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

Stephen Purcell wrote:

> > [backticks etc.]
>
> This is probably not the simplest way to do things. Looks like some
> smart combination of __import__ and the 'imp' and 'rexec' modules is the
> simplest* solution, but hardly the most obvious.

I think in these terms of simplicity that running the actual test in a new
process is simpler. The logic is very easy - get the test name, pipe it to a
new copy of yourself. parsing the results is as easy as a while loop that
continuously reads for new output.

> * Note: simplicity is here measured in lines of code and maintainability

The only other solution I can think of is reloading every module in
sys.modules. The GUI could keep a list of which it was using, and reload all
the others. As for chaining errors I think this could be solved by reloading
the set of modules twice.

> The CGI test runner idea is a cool one. Talk about a cross-platform GUI!

Indeed. The disadvantage is that it is hard to make the results realtime. Most
tests take only seconds to run. However a large project that has thousands of
tests and takes minutes to run would not get any feedback from the cgi until
all the tests have been run, even if the first failed. Of course there is the
option of a server side push or even a reload/refresh, both of which I'm quite
familiar with.


--
Nathan Heagy
------------
Blow Your Beef Away
http://cowcomics.com

Re: [Pyunit-interest] Modifications to PyUnit

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

Nathan R Heagy wrote:
> 
> The only reason I put it in the Constructor for TestSuite is because
> this is where I thought I found it in JUnit. That's it.

I think there are good arguments on both sides. I suspect that the best
place for such code depends upon how often TestSuite is likely to get
subclassed.

> >3.) There are complications with reloading modules -- see the recent
> >discussions on the list between Shae and myself. To reload the test
> >module is not enough to ensure that the tested module is reloaded too.
> 
> That is true. It's something I'll be working on for sure. I do have a few
> ideas though. My background is in perl, so I'm not sure how easy or 
> natural this would be in python:

Off hand response: "At least as easy as in perl."  <grin>

> [backticks etc.]

This is probably not the simplest way to do things. Looks like some
smart combination of __import__ and the 'imp' and 'rexec' modules is the
simplest* solution, but hardly the most obvious.

* Note: simplicity is here measured in lines of code and maintainability

The CGI test runner idea is a cool one. Talk about a cross-platform GUI!
Perhaps even a test server based on the standard library's
BaseHTTPServer would be interesting; any way that could be used to embed
testing capabilities in a larger environment is inherently interesting.
I know some Zope people are crying out for that kind of embedded test
functionality.

Best wishes,

-Steve

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

Re: [Pyunit-interest] Modifications to PyUnit

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

>Hi Nathan,
>
>The GUI looks cool; thanks for sending it in. I have a few comments
>overall, which may or may not help you:


Thanks for the quick response!

>1.) The ability to create a TestSuite instance from a TestCase class
>containing conventionally named methods is actually already provided by
>the outboard function 'unittest.makeSuite()'. I think I prefer this to
>altering the TestSuite constructor.


The only reason I put it in the Constructor for TestSuite is because this is
where I thought I found it in JUnit. That's it.

>3.) There are complications with reloading modules -- see the recent
>discussions on the list between Shae and myself. To reload the test
>module is not enough to ensure that the tested module is reloaded too.


That is true. It's something I'll be working on for sure. I do have a few
ideas though. My background is in perl, so I'm not sure how easy or natural
this would be in python:

Execute a new instance of the TestResult as a seperate program and parse the
results. In perl I would use backticks to do this. Then the main problem is
keeping track of current working directories and program location.


The other possibility I'm looking at is creating a CGI version with a HTML
form GUI. This is what I did with php, and it worked quite well.

Nathan R Heagy
. . . . . . . . . . . . . .
Blow Your Beef Away
http://cowcomics.com

[Pyunit-interest] Tkinter GUI test runner

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

Okay, here's a questionable treat; I've stuck my initial and incomplete
stab at a Tkinter GUI on the site. It dates from months ago, but it at
least works with the listtests and widgettests examples (provided the
module path is set up appropriately first).

It's (impermanently) available at:

  ftp://pyunit.sourceforge.net/pub/pyunit/tkgui/unittestgui.py

There's not much error handling, no progress bar, and no detailed
display of errors. Oh, and no reloading of modules. But anyway, it gives
an idea of what I had in mind. Any takers? Shae? :-)

Best wishes to all,

-Steve

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

Re: [Pyunit-interest] Modifications to PyUnit

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

Nathan Heagy wrote:
> 
> I've made some modifications to PyUnit on my own. I made them so I can
> use PyUnit the way I use other Unit Tests frameworks based on JUnit. I
> don't think they are production quality (for anyone but me, that is) so
> if I could get some feedback I am interested in making changes so that I
> can formally submit them to PyUnit.

Hi Nathan,

The GUI looks cool; thanks for sending it in. I have a few comments
overall, which may or may not help you:

1.) The ability to create a TestSuite instance from a TestCase class
containing conventionally named methods is actually already provided by
the outboard function 'unittest.makeSuite()'. I think I prefer this to
altering the TestSuite constructor.

2.) Take a look at 'unittest.createTestInstance()'. This function takes
a fully qualified string name for a callable object that returns a
TestCase or TestSuite instance. I've used it for the command-line
operation of the unittest module itself with TextTestRunner, and with
the fledgling Tkinter GUI I started months ago. It would probably suit
your needs too. Then you don't need to implicitly create TestSuites to
wrap the test names entered by the user. I'll try to send back an
appropriate patch if time allows. (Doing an 'import *' from within the
test runner is probably a bit dangerous in terms of namespace pollution)

3.) There are complications with reloading modules -- see the recent
discussions on the list between Shae and myself. To reload the test
module is not enough to ensure that the tested module is reloaded too.

Best wishes, and thanks again!

-Steve

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

[Pyunit-interest] Modifications to PyUnit

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

I've made some modifications to PyUnit on my own. I made them so I can
use PyUnit the way I use other Unit Tests frameworks based on JUnit. I
don't think they are production quality (for anyone but me, that is) so
if I could get some feedback I am interested in making changes so that I
can formally submit them to PyUnit.

A tarball of the changes are available at :
    http://heagy.com/unittest-mod.tar.gz

Changes:
    * TestSuite will now accept a Class on construction. It searches the
class for methods that being with "test_" or "Test_" and adds them to
the suite automatically.
    * A GUI based on wxWindows is included. Currently it assumes you
want to import * from ClassName, and also assumes that you want to use
the new style suite creation.

Included in the tarball:
    * modified unittest.py
    * diff file of changes
    * wxGui.py
    * A class and its test class that use the new style suite
construction so that you can test the GUI right away

All comments are welcome,

Nathan Heagy
Blow Your Beef Away
http://cowcomics.com

Re: [Pyunit-interest] Invarient

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

"Frank V. Castellucci" wrote:
> 
> I'm a big believer and practitioner of B. Meyers assertion model in
> regards to state invariance. Has the PyUnit team consider a way to
> provide this type testing for Python class and instance? Or is it all
> covered in the existing implementation?

Hi Frank,

Thanks for the question.

I think Unit Testing and Invariance Checking are quite separate things,
and as such, provision of direct support for invariance checking is
outside the scope of PyUnit. Python's built-in 'assert' statement is
there for those who wish to sprinkle it liberally inside their classes,
and Meyer enthusiasts who do so will find that PyUnit recognises as
failures any checked invariants that are violated during a test run.

That's the essence of my reply, but I'll indulge myself by throwing in a
few personal views...

I'm actually a skeptic of the Meyer assertion model, although I am aware
that many other people consider it helpful. My highly personal feeling
is that invariance checking plays an insignificant role in the assurance
that a class works correctly. I would postulate that, for a given class,
there is no invariant whose religious preservation assures that the
class will do what it promises.

Developers want to ensure that their code works properly in all the
conditions in which it has been designed to be used. In my (and the
Extreme Programming) view, unit tests document and test those
'designed-for' conditions, and if the code breaks in any situation not
covered by a unit test, it is being used contrary to the author's plans.
In those breakage cases, invariant assertions could provide helpful
feedback, but I personally would not spend a lot of time writing
assertions that only help if my code is misused. Unit tests *are* the
contract in the XP world view.

Some relevant Wiki wisdom:-

 http://c2.com/cgi/wiki?DesignByContractAssertionsVsUnitTestsVsTypes
 http://c2.com/cgi/wiki?DoNotUseAssertions
 http://c2.com/cgi/wiki?UseAssertions
 http://c2.com/cgi/wiki?YouArentGonnaNeedIt
 http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork

It's an area of quite some controversy.

Best wishes,

-Steve

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

[Pyunit-interest] Invarient

[Frank V. C. <fr...@co...>]

Hello,

I'm a big believer and practitioner of B. Meyers assertion model in
regards to state invariance. Has the PyUnit team consider a way to
provide this type testing for Python class and instance? Or is it all
covered in the existing implementation?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Pyunit-interest] Release 1.1.0

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

Hi folks,

I just made a new release of PyUnit, something that I don't plan to do
very often.

Thanks to all for the suggestions.

Summary of the changes follows:

* Changed 'makeSuite' so that test cases functions in base
  classes of the given test case class are also found. This
  allows re-use of test code with different set-up code. See
  'listtests' example. (Thanks to Lars Marius  Garshol.)
* Added sorting functionality to 'makeSuite' function.
  (Suggested by Kevin Butler)
* Changes to documentation (clarifications, notes about
  new functionality)
* Added 'assertRaises' method to TestCase
* Added 'fail' method to TestCase
* Added 'listtests.py' and 'alltests.py' examples

You can download the latest version from http://pyunit.sourceforge.net/

Any feedback would, as ever, be greatly appreciated.

Very best wishes,

-Steve

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

[Pyunit-interest] Supported platforms

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

I'd love to hear from anyone out there who is using PyUnit on platforms
other than Redhat Linux, just so I know where it works and where it
doesn't...

Thanks,

-Steve

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

Re: [Pyunit-interest] feature and usage questions.

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

Shae Erisson wrote:
> 
> yes, this was my problem, I corrected it by downloading the latest
> version of PyUnit (oops).

Hmmm. Wonder what it was that I changed between releases...

> The latest downloadable version of PyUnit doesn't have an addSuite.
> 
> Ah, upon further reading of this email,
> alltests.addTest(test_ast.suite()) _does_ work. This is exactly what I
> wanted.

Sorry; my rushed typo.

> [reloading modules]

The imported modules list is even easier to get: sys.modules

The problem is more complex than that, though. 'reload' only affects the
module definition (i.e. implementation) imported into the current
namespace, so I have a suspicion that there's an issue with chaining.
Imports form a tree structure through all modules, so the order of
reloading of modules makes a big difference.

Consider modules 'foo' and 'bar' in this session:

% cat foo.py
version = 1
UNIX % cat bar.py
from foo import version
% python
Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66
19990314/Linux (egcs- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import foo,bar
>>> foo.version, bar.version
(1, 1)
>>> f = open('foo.py','w')
>>> f.write('version = 2\n') # change foo module
>>> f.close()
>>> reload(bar)
<module 'bar' from 'bar.pyc'>
>>> foo.version, bar.version
(1, 1)
>>> reload(foo) 
<module 'foo' from 'foo.py'>
>>> foo.version, bar.version
(2, 1)
>>> reload(bar)
<module 'bar' from 'bar.pyc'>
>>> foo.version, bar.version
(2, 2)

> It is quite fiddly though :(

Hey, *I'd* be disappointed if it wasn't. <grin>

-Steve

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

Re: [Pyunit-interest] feature and usage questions.

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

Stephen Purcell wrote:
> 
> Shae Erisson wrote:
> >
> > Yay PyUnit! It's easy to use and it helps me find bugs!
> >
> > It's not perfect though :)
> 
> Admit it, you'd be disappointed if it was. :-)

I agree. I would!

> Run: 1 Failures: 0 Errors: 1
> There was 1 error:
> 1) __main__.MyTestCase.checkSomething
> Traceback (innermost last):
>   File "<stdin>", line 3, in checkSomething
> NameError: oops

yes, this was my problem, I corrected it by downloading the latest
version of PyUnit (oops).

>  import test_ast, test_brm, unittest
>  alltests = unittest.TestSuite()
>  alltests.addSuite(test_ast.suite())
>  alltests.addSuite(test_brm.suite())

The latest downloadable version of PyUnit doesn't have an addSuite.

Ah, upon further reading of this email,
alltests.addTest(test_ast.suite()) _does_ work. This is exactly what I
wanted.

> > As for Tk GUI support, what about sticking support for PyUnit into IDLE?
> 
> That's a thoroughly excellent idea.
> 
> Haven't got my head enough into (inter?) Tk to offer my services at this
> point. I'd like to get a good clone of the basic JUnit GUI, but if it
> could be used with IDLE as well as standalone, that would be wonderful.
> I started on a GUITestRunner, but didn't get far. One nice feature of
> JUnit is that all classes are reloaded automatically between test runs,
> so the GUI need not be restarted constantly. Think it might be more
> fiddly with Python (hard to believe, but that's my suspicion).

Here's the process I came up with(after some discussion on IRC):

make sure you run tearDown, then:

def getImportedModules(mod): 
    return filter(lambda (x,y): type(y) is types.ModuleType,
vars(mod).items())

for module in getImportedModules(modname):
    reload(module)

This would only work if you knew the name of module that had the tests
defined in it though, and if no import x from y lines were in it.
I don't know how a GUITestRunner would know which module it was started
from, though I may be missing something obvious.
The only solution I can think of to the above two problems is loading
the test definitions from a dialog or something, not calling the GUI
from the tests file.

It is quite fiddly though :(
-- 
sHae mAtijs eRisson (sH...@wE...) gEnius fOr hIre
   bRing mE fIve sQuirrels aNd nO oNe wIll gEt hUrt
13:00pm up 1 season, 1 squirrel, load average: 1+1j 0.5+2j 0.2+0.5j

Re: [Pyunit-interest] feature and usage questions.

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

Shae Erisson wrote:
> 
> Yay PyUnit! It's easy to use and it helps me find bugs!
> 
> It's not perfect though :)

Admit it, you'd be disappointed if it was. :-)

> One thing I'm running across is that NameError (eg. the method doesn't
> even exist yet) comes back as a Failure, not as an Error, is this the
> correct behaviour?

Not quite sure what case you mean. I guessed that you meant the
following, which seems to work correctly, so I'm obviously missing
something:

>>> import unittest
>>> 
>>> class MyTestCase(unittest.TestCase):
...   def theTestMethod(self):
...     assert 1
... 
>>> MyTestCase()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "unittest.py", line 104, in __init__
    raise ValueError,"no such test method: %s" % methodName
ValueError: no such test method: runTest
>>> MyTestCase('theTestMethod')
<__main__.MyTestCase instance at 8108220>

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

also,

>>> import unittest
>>> class MyTestCase(unittest.TestCase):
...   def checkSomething(self):
...     raise NameError, 'oops' 
... 
>>> unittest.TextTestRunner().run(MyTestCase('checkSomething'))
.E
Time: 0.000s

!!!FAILURES!!!
Test Results

Run: 1 Failures: 0 Errors: 1
There was 1 error:
1) __main__.MyTestCase.checkSomething
Traceback (innermost last):
  File "<stdin>", line 3, in checkSomething
NameError: oops

<unittest.TextTestResult run=1 errors=1 failures=0>


> Also, I'd like to be able merge suites, is there some way to do that?
> Right now I have a test_ast.py and a test_brm.py and they both build
> suites, I know I can use:
> #test_all.py:
> import test_ast
> ...
> suite.addTest(test_ast.ASTTestCase("checkFileLoads"))
> suite.addTest(test_brm.BRMTestCase("checkFileLoads"))
> but that requires code duplication(yuk) if I want test_brm to be able to
> run its own tests by itself.
> Any suggestions?

Nesting suites within each other is the usual way to accomplish what you
want.

In this case, I would tend to define an AST suite in test_ast, and a BRM
test suite in test_brm. Then, in test_all, I would use

 import test_ast, test_brm, unittest
 alltests = unittest.TestSuite()
 alltests.addSuite(test_ast.suite())
 alltests.addSuite(test_brm.suite())

As Michal points out, choosing a naming convention for the 'suite'
factory methods may save a little time when you have lots of modules to
test:

 modules_to_test = ('test_ast', 'test_brm', 'test_thg') # and so on
 alltests = unittest.TestSuite()
 for module in map(__import__, modules_to_test):
   alltests.addTest(module.suite())

(didn't try this out, but I think it should work)

If you slurp modules_to_test out of a directory listing, you get the
kind of functionality that Michal suggests.

> I admit, wanting one single report from multiple suites is a case of me
> being nitpicky...

No, it's a normal requirement. 

> As for Tk GUI support, what about sticking support for PyUnit into IDLE?

That's a thoroughly excellent idea.

Haven't got my head enough into (inter?) Tk to offer my services at this
point. I'd like to get a good clone of the basic JUnit GUI, but if it
could be used with IDLE as well as standalone, that would be wonderful.
I started on a GUITestRunner, but didn't get far. One nice feature of
JUnit is that all classes are reloaded automatically between test runs,
so the GUI need not be restarted constantly. Think it might be more
fiddly with Python (hard to believe, but that's my suspicion).


-Steve

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

Re: [Pyunit-interest] feature and usage questions.

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

"Michal Wallace (sabren)" wrote:

> I made a generic tool that looks for a suite called "suite", or a
> dictionary called "suites" in a module called "test"... It just runs
> whatever it finds.. It's pretty simple, but if you want it, you could
> probably modify it fairly easily to take a module name as a
> parameter..

Sure! Send it over!

> :) I know brm is bicycle repair man.. What's ast? Abstract syntax tree?
> how's the project coming, btw? :)

Yes, it is AbstractSyntaxTree, which means I'm making progress, slowly.
No detail here, as I think it's too off-topic.

(but this part is on-topic)
One of the reasons I'm insidiously trying to get IDLE as the Tk GUI for
PyUnit is that refactorings are only provably correct if they pass their
associated unit tests after a refactoring.
This means PyUnit is necessary to my project, and if no one else writes
an IDLE extension to build/run PyUnit tests, then I will. :)
-- 
sHae mAtijs eRisson (sH...@wE...) gEnius fOr hIre
   bRing mE fIve sQuirrels aNd nO oNe wIll gEt hUrt
13:00pm up 1 season, 1 squirrel, load average: 1+1j 0.5+2j 0.2+0.5j

Re: [Pyunit-interest] feature and usage questions.

[Michal W. (sabren) <sa...@ma...>]

On Wed, 17 May 2000, Shae Erisson wrote:

> Also, I'd like to be able merge suites, is there some way to do that?
> Right now I have a test_ast.py and a test_brm.py and they both build
> suites, I know I can use:
> #test_all.py:
> import test_ast
> ...
> suite.addTest(test_ast.ASTTestCase("checkFileLoads"))
> suite.addTest(test_brm.BRMTestCase("checkFileLoads"))
> but that requires code duplication(yuk) if I want test_brm to be able to
> run its own tests by itself. 
> Any suggestions?


I made a generic tool that looks for a suite called "suite", or a
dictionary called "suites" in a module called "test"... It just runs
whatever it finds.. It's pretty simple, but if you want it, you could
probably modify it fairly easily to take a module name as a
parameter..

> I admit, wanting one single report from multiple suites is a case of me
> being nitpicky... 

Not at all. I'm often working with many different libraries at once, and
I want to be able to test them independently, or test the whole lot of
whatever's relevent to my program..

:) I know brm is bicycle repair man.. What's ast? Abstract syntax tree? 
how's the project coming, btw? :)

Cheers,

- Michal
-------------------------------------------------------------------------
http://www.manifestation.com/         http://www.linkwatcher.com/metalog/
-------------------------------------------------------------------------

[Pyunit-interest] feature and usage questions.

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

Yay PyUnit! It's easy to use and it helps me find bugs!

It's not perfect though :)
One thing I'm running across is that NameError (eg. the method doesn't
even exist yet) comes back as a Failure, not as an Error, is this the
correct behaviour?

Also, I'd like to be able merge suites, is there some way to do that?
Right now I have a test_ast.py and a test_brm.py and they both build
suites, I know I can use:
#test_all.py:
import test_ast
...
suite.addTest(test_ast.ASTTestCase("checkFileLoads"))
suite.addTest(test_brm.BRMTestCase("checkFileLoads"))
but that requires code duplication(yuk) if I want test_brm to be able to
run its own tests by itself. 
Any suggestions?
I admit, wanting one single report from multiple suites is a case of me
being nitpicky... 

As for Tk GUI support, what about sticking support for PyUnit into IDLE?
I recently found a page[1] for software that integrates JUnit into IBM
VisualAge for Java. Possibly IDLE would be a good platform for a PyUnit
builder/runner?

[1] http://www.xpdeveloper.com/cgi-bin/wiki.cgi?BigBenTools
-- 
sHae mAtijs eRisson (sH...@wE...) gEnius fOr hIre
   bRing mE fIve sQuirrels aNd nO oNe wIll gEt hUrt
13:00pm up 1 season, 1 squirrel, load average: 1+1j 0.5+2j 0.2+0.5j

[Pyunit-interest] comments, thoughts

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

I think PyUnit is great... but much like some of the Wiki pages I've
seen, I'm not sure I have much else to say... I can't think of any
improvements for it, nor have I found any problems with it. I would use
a Tk gui though.

Does anyone have any suggestions on dividing functional tests from unit
tests with PyUnit?

Random Note: I'm quite happy PyUnit has a Python style redistribution
license, as I'm writing a Python Refactoring Browser and PyUnit will be
the standard unit testing module for it.
-- 
sHae mAtijs eRisson (sH...@wE...) gEnius fOr hIre
   bRing mE fIve sQuirrels aNd nO oNe wIll gEt hUrt
13:00pm up 1 season, 1 squirrel, load average: 1+1j 0.5+2j 0.2+0.5j

Re: [Pyunit-interest] pyunit command

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

Hi Michal (and all),

I'm very happy that you have taken the time to describe your
experiences, and your suggestions make a lot of sense.

When projects amass a large number of tests, they absolutely *must* be
organised sanely. Such sanity is a subjective standard, and would
necessarily vary from project to project. I would therefore be wary of
suggesting a 'general' convention for this kind of thing, even if you
and I would probably do things the way you describe.

The DistUtil case is an important one to consider. From what I can see,
the DistUtil people do not impose any particular structure on
distributions, except for the presence of an appropriately capable
'setup.py' that can programmatically oversee compilation, installation,
testing and so on.

A 'setup.py' could work quite easily with the existing framework code,
so the question is how to conveniently arrange sets of tests. I would
tend to stick with explicitly grouping test cases into suites, and then
grouping those suites into further high-level suites. Others may prefer
to automagically construct suites based on naming conventions (*.suite()
etc).

I will get in touch with Greg Stein, who seems to be doing much of the
DistUtils work, and see what he thinks.

Very best wishes,

-Steve

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

[Pyunit-interest] pyunit command

[Michal W. (sabren) <sa...@ma...>]

Hey all,

   I have a suite of python programs and modules, and am trying to
standardize my test process.. I was wondering how other people tended
to do this, but haven't found much in the way of documentation. For
example, here's what I'm currently planning to do:

   * For every project/module, have a module called test.py
     (or test/__init__.py ) in the top level directory.

   * If using a test directory, each submodule will define a test
     suite named "suite"..

   * The main test module will define EITHER a test suite named "suite"
     (fancy that!), OR for more complex modules, a dictionary of named
     of test suites named "suites", eg  suites={"mysuite":submodule.suite}


   Given standards like the above, it's fairly easy to write a command
called pyunit that does an "import test" and runs test.suite or each
test in test.suites. This routine could be bundled with PyUnit.

   Standards also open up the possibility for, say, an automated
routine to check out CVS sources for a project, test it, and if
everything passes, create a nightly tarball. 

  I'm actually going to be writing the two above scripts, and hope to
add them to the main pyunit distribution if other people are willing
to adapt a standard location and naming convention (otherwise, they'd
get too complex)

   As far as I can tell, the DistUtils http://www.python.org/sigs/distutils-sig/
don't yet seem to have a standard for testing.. If we can agree on a standard
way to name things, then PyUnit has a good chance of becoming the standard
way of testing for all pythonland.

   The easy thing to do would be to add these standards as suggestions
in the docs. 

Whatcha think?

Cheers,

- Michal
-------------------------------------------------------------------------
http://www.manifestation.com/         http://www.linkwatcher.com/metalog/
-------------------------------------------------------------------------