pyunit-interest

RE: [Pyunit-interest] comments on PyUnit

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

"test"

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Luigi
Ballabio
Sent: Tuesday, July 03, 2001 11:54 AM
To: Pyunit-Interest
Subject: Re: [Pyunit-interest] comments on PyUnit

At 11:40 AM 7/3/01 -0500, Michal Wallace wrote:
>On Tue, 3 Jul 2001, Guido van Rossum wrote:
>
> > - But for some of the functions, noone came up with a reasonable name
> >   that doesn't use "assert".
>
>"expect"?

"require"? "ensure"?

Bye,
         Luigi



_______________________________________________
Pyunit-interest mailing list
Pyu...@li...
http://lists.sourceforge.net/lists/listinfo/pyunit-interest

Re: [Pyunit-interest] comments on PyUnit

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

John J. Lee wrote:
> IIRC, Jeremy Hylton suggested 'verify'.  Didn't that get implemented?


No. The names that got implemented were those that were chosen in the
discussions on this list in April. There are undoubtedly many more possible
aliases for them, but the set of names is now frozen, for the sake of
everyone's sanity. (Even a fuzzy standard is a step forward!)

-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] comments on PyUnit

[John J. L. <ph...@cs...>]

On Tue, 3 Jul 2001, Luigi Ballabio wrote:

> At 11:40 AM 7/3/01 -0500, Michal Wallace wrote:
> >On Tue, 3 Jul 2001, Guido van Rossum wrote:
> >
> > > - But for some of the functions, noone came up with a reasonable name
> > >   that doesn't use "assert".
> >
> >"expect"?
>
> "require"? "ensure"?
>

IIRC, Jeremy Hylton suggested 'verify'.  Didn't that get implemented?


John

Re: [Pyunit-interest] comments on PyUnit

[Luigi B. <bal...@ma...>]

At 11:40 AM 7/3/01 -0500, Michal Wallace wrote:
>On Tue, 3 Jul 2001, Guido van Rossum wrote:
>
> > - But for some of the functions, noone came up with a reasonable name
> >   that doesn't use "assert".
>
>"expect"?

"require"? "ensure"?

Bye,
         Luigi

Re: [Pyunit-interest] comments on PyUnit

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

On Tue, 3 Jul 2001, Guido van Rossum wrote:

> - But for some of the functions, noone came up with a reasonable name
>   that doesn't use "assert".

"expect"?

Cheers,

- Michal
------------------------------------------------------------------------
www.manifestation.com  www.sabren.net  www.linkwatcher.com  www.zike.net
------------------------------------------------------------------------

Re: [Pyunit-interest] comments on PyUnit

[Guido v. R. <gu...@di...>]

Don't look at me to break this tie!  I haven't bee paying enough
attention to be of much help.  Make a proposal.

Some of the forces that go into this:

- Using "assert" sends the wrong message because it suggests an
  equivalence with assert statements, but those are disabled under
  certain compilation options (ditto for the choice to raise
  AssertionError).

- But for some of the functions, noone came up with a reasonable name
  that doesn't use "assert".

--Guido van Rossum (home page: http://www.python.org/~guido/)

> Subject: RE: [Pyunit-interest] comments on PyUnit
> From: "Patrick K. O'Brien" <po...@or...>
> To: "Pyunit-Interest" <pyu...@li...>,
>     "Guido van Rossum" <gu...@di...>
> Date: Mon, 2 Jul 2001 15:36:14 -0500
> X-Loop-Detect: 1
> 
> With the benefit of some couple of months behind us, and with the inclusion
> of unittest in the standard Python distro, will there be any consensus on
> which version of these method names to use? Will there be one Python way, or
> are we doomed to an unusual amount of variety? I'm asking from the point of
> view of someone who doesn't have a lot of legacy pyUnit code. I see an
> opportunity for Python to introduce good coding habits, which is why I'm
> sure you all pushed for unittest as part of the standard library.
> 
> Unfortunately, one is left with a rather schizophrenic implementation in a
> couple of ways. First, the documentation
> (http://www.python.org/doc/current/lib/testcase-objects.html) lists both
> method names without any indication as to why there are two and which is to
> be preferred. One could assume that the assert* is better as it is listed
> first. But it might also simply be in alphabetical order. Then one looks at
> the code as sees the methods defined with the fail* name and the following
> synonyms:
> 
>     assertEqual = assertEquals = failUnlessEqual
> 
>     assertNotEqual = assertNotEquals = failIfEqual
> 
>     assertRaises = failUnlessRaises
> 
>     assert_ = failUnless
> 
> This would seem to imply that the fail versions are to be preferred. Of
> course, the other language testing frameworks use the assert versions, as
> does Mark Pilgrim's excellent tutorial. Looking at the unit tests that test
> Python itself we can even find "verify." This is all too confusing to
> someone as anal retentive as I am. So I am asking for a word from on high.
> If one were starting from square one and wanted to write unit tests the
> Python way, what way would that be?
> 
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
> 
> -----Original Message-----
> From: pyu...@li...
> [mailto:pyu...@li...]On Behalf Of Guido van
> Rossum
> Sent: Thursday, April 12, 2001 1:54 PM
> To: Steve Purcell
> Cc: Fred L. Drake, Jr.; pyu...@li...
> Subject: Re: [Pyunit-interest] comments on PyUnit
> 
> > Fred L. Drake, Jr. wrote:
> > >   I notice that it still isn't calling TestCase.fail() in all the
> > > fail<Something>() methods -- were we still agreed on that?  I can make
> > > that change is needed.
> >
> Steve:
> > I decided against that; the extra level of traceback output is unsightly.
> 
> Agreed.
> 
> > The failure exception is now parameterised, and the framework is not
> written
> > such that it would be safe and/or desirable to override fail() in
> subclasses.
> 
> OK, fine.
> 
> > >   Since Guido's suggested we document both naming famillies, we should
> > > have a second name for this -- I suggest "assertNot()".
> >
> > I also decided against this; fail() does not have a common-sense
> > 'assert' counterpart, and 'assertNot' is better served by 'assert_(not
> expr)'
> > for those users who prefer 'assert*' to 'fail*'.
> 
> Agreed.
> 
> > A bit of relevant background: JUnit lives quite happily with the
> following:
> >
> >     fail()
> >     assert(expr)
> >     assertEquals(a,b)
> >     assertSame(a,b)
> 
> But Java doesn't have an assert statement in the language!
> 
> > If I were starting PyUnit from scratch, I would provide only:
> >
> >     fail()
> >     assert_(expr)
> 
> This is an ugly name, though (and that's what started this debate).
> 
> >     assertEquals(a,b)
> 
> Why even bother with this?  I'd say assert_(a == b) is good enough.
> 
> >     assertRaises(exception,func,*args,**kwargs)
> 
> This is a useful utility.
> 
> But, the problems I pointed out with assert will remain as long as we
> have names starting with assert...  :-(
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> http://lists.sourceforge.net/lists/listinfo/pyunit-interest

Re: [Pyunit-interest] comments on PyUnit

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

Steve Purcell writes:
 > If you're looking for standardisation, use whatever names the
 > PythonLabs guys are using in the Python regression tests.

  I don't think we've even talked about picking a specific set of
names.  If it's documented in the library reference, it's fair game
and will be maintained in the Python standard library.  What makes the
most sense will often depend on the surrounding code and the intent of
the test.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

Re: [Pyunit-interest] comments on PyUnit

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

Patrick K. O'Brien wrote:
> With the benefit of some couple of months behind us, and with the inclusion
> of unittest in the standard Python distro, will there be any consensus on
> which version of these method names to use? Will there be one Python way, or
> are we doomed to an unusual amount of variety? I'm asking from the point of
> view of someone who doesn't have a lot of legacy pyUnit code.


The answer is almost too simple -- consistently use whichever method names
lead to clearer test code, according to your personal aesthetic sense.
There are aliases for the names because nobody can agree on the clearest
set of names, and because of PyUnit's JUnit heritage.

If you're looking for standardisation, use whatever names the PythonLabs
guys are using in the Python regression tests.

Personally I'll stick with my bizarre favoured combination of 'assertEquals',
'failUnless' and 'failIf'.

Check back in the archives of this list from April to find out what the
thinking was behind the aliased naming scheme.

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] comments on PyUnit

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

With the benefit of some couple of months behind us, and with the inclusion
of unittest in the standard Python distro, will there be any consensus on
which version of these method names to use? Will there be one Python way, or
are we doomed to an unusual amount of variety? I'm asking from the point of
view of someone who doesn't have a lot of legacy pyUnit code. I see an
opportunity for Python to introduce good coding habits, which is why I'm
sure you all pushed for unittest as part of the standard library.

Unfortunately, one is left with a rather schizophrenic implementation in a
couple of ways. First, the documentation
(http://www.python.org/doc/current/lib/testcase-objects.html) lists both
method names without any indication as to why there are two and which is to
be preferred. One could assume that the assert* is better as it is listed
first. But it might also simply be in alphabetical order. Then one looks at
the code as sees the methods defined with the fail* name and the following
synonyms:

    assertEqual = assertEquals = failUnlessEqual

    assertNotEqual = assertNotEquals = failIfEqual

    assertRaises = failUnlessRaises

    assert_ = failUnless

This would seem to imply that the fail versions are to be preferred. Of
course, the other language testing frameworks use the assert versions, as
does Mark Pilgrim's excellent tutorial. Looking at the unit tests that test
Python itself we can even find "verify." This is all too confusing to
someone as anal retentive as I am. So I am asking for a word from on high.
If one were starting from square one and wanted to write unit tests the
Python way, what way would that be?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Guido van
Rossum
Sent: Thursday, April 12, 2001 1:54 PM
To: Steve Purcell
Cc: Fred L. Drake, Jr.; pyu...@li...
Subject: Re: [Pyunit-interest] comments on PyUnit

> Fred L. Drake, Jr. wrote:
> >   I notice that it still isn't calling TestCase.fail() in all the
> > fail<Something>() methods -- were we still agreed on that?  I can make
> > that change is needed.
>
Steve:
> I decided against that; the extra level of traceback output is unsightly.

Agreed.

> The failure exception is now parameterised, and the framework is not
written
> such that it would be safe and/or desirable to override fail() in
subclasses.

OK, fine.

> >   Since Guido's suggested we document both naming famillies, we should
> > have a second name for this -- I suggest "assertNot()".
>
> I also decided against this; fail() does not have a common-sense
> 'assert' counterpart, and 'assertNot' is better served by 'assert_(not
expr)'
> for those users who prefer 'assert*' to 'fail*'.

Agreed.

> A bit of relevant background: JUnit lives quite happily with the
following:
>
>     fail()
>     assert(expr)
>     assertEquals(a,b)
>     assertSame(a,b)

But Java doesn't have an assert statement in the language!

> If I were starting PyUnit from scratch, I would provide only:
>
>     fail()
>     assert_(expr)

This is an ugly name, though (and that's what started this debate).

>     assertEquals(a,b)

Why even bother with this?  I'd say assert_(a == b) is good enough.

>     assertRaises(exception,func,*args,**kwargs)

This is a useful utility.

But, the problems I pointed out with assert will remain as long as we
have names starting with assert...  :-(

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Pyunit-interest mailing list
Pyu...@li...
http://lists.sourceforge.net/lists/listinfo/pyunit-interest

Re: [Pyunit-interest] Confused about docstrings in unittest.py

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

Patrick K. O'Brien writes:
 > In the version of unittest.py that shipped with Python 2.1, why are some
 > docstrings triple-quoted while others are single-quoted (and therefore not
 > docstrings?). Here is an example, where failIf has only single quotes:

  Docstring detection in Python is not based on the type of quoting;
they can be either single- or triple-quoted, "raw" or traditional, and
quoted with either single or double quotes.  Check the __doc__
attributes of those methods and you'll see that the docstrings are
indeed in place.
  The only requirement for docstrings is that they be string literals
(possibly composed of multiple concatenated parts) and the first
statement of their enclosing scope.
  For example, this function has a legitimate docstring:

def func():
    'This function '  "has" ''' a very
    strangely '''\
    r'quoted docstring.' \
    r"""I would not recommend this."""



  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

[Pyunit-interest] Confused about docstrings in unittest.py

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

In the version of unittest.py that shipped with Python 2.1, why are some
docstrings triple-quoted while others are single-quoted (and therefore not
docstrings?). Here is an example, where failIf has only single quotes:

    def fail(self, msg=None):
        """Fail immediately, with the given message."""
        raise self.failureException, msg

    def failIf(self, expr, msg=None):
        "Fail the test if the expression is true."
        if expr: raise self.failureException, msg

    def failUnless(self, expr, msg=None):
        """Fail the test unless the expression is true."""
        if not expr: raise self.failureException, msg

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

RE: [Pyunit-interest] Converting Python's test suite to PyUnit?

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

Thank you, Steve, for answering all my q's. Everything is working fine now.
And I had forgot about Mark Pilgrim's new chapter. I think I'll go for a
swim. <g>

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Steve
Purcell
Sent: Wednesday, June 27, 2001 2:00 AM
To: Patrick K. O'Brien
Cc: pyu...@li...
Subject: Re: [Pyunit-interest] Converting Python's test suite to PyUnit?

Patrick K. O'Brien wrote:
> I'm just starting to use the unittest module to create some tests for my
own
> code. I started by gettting the rewritten python tests from the Python CVS
> to use as role models.

The best way to start would be with the superb unit testing chapter of
Mark Pilgrim's online book 'Dive into Python':

     http://diveintopython.org/roman_divein.html

> I notice that they make use of
> test_support.run_unittest(). The test_support module is not on the default
> Python Path and doesn't seem to really be part of the unit testing
> framework.

In this case, 'test_support' is used only to fit the tests based on
PyUnit (ie. 'unittest') into the existing Python regression test framework.

> So, should I not be using test_support for my own tests?

Correct.

> Is there a simple
> equivalent that would allow me to look at the python tests (such as
> test_time.py and test_pprint.py) yet understand how I should run the tests
> if they were part of my own code?

The tests you mention are completely normal PyUnit tests; they are built
using sublasses of 'unittest.TestCase'. The only unusual
thing is that they are run by 'test_support.run_unittest()' and not by
the usual PyUnit mechanism (using 'unittest.main()' or
unittest.TextTestRunner). To run the tests solely using PyUnit, the same
test case classes could be placed in a module containing the usual
PyUnit module-level clause:

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

Hope that answers the question.

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] Converting Python's test suite to PyUnit?

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

Patrick K. O'Brien wrote:
> I'm just starting to use the unittest module to create some tests for my own
> code. I started by gettting the rewritten python tests from the Python CVS
> to use as role models.

The best way to start would be with the superb unit testing chapter of
Mark Pilgrim's online book 'Dive into Python':

     http://diveintopython.org/roman_divein.html

> I notice that they make use of
> test_support.run_unittest(). The test_support module is not on the default
> Python Path and doesn't seem to really be part of the unit testing
> framework.

In this case, 'test_support' is used only to fit the tests based on
PyUnit (ie. 'unittest') into the existing Python regression test framework.

> So, should I not be using test_support for my own tests?

Correct.

> Is there a simple
> equivalent that would allow me to look at the python tests (such as
> test_time.py and test_pprint.py) yet understand how I should run the tests
> if they were part of my own code?

The tests you mention are completely normal PyUnit tests; they are built
using sublasses of 'unittest.TestCase'. The only unusual
thing is that they are run by 'test_support.run_unittest()' and not by
the usual PyUnit mechanism (using 'unittest.main()' or
unittest.TextTestRunner). To run the tests solely using PyUnit, the same
test case classes could be placed in a module containing the usual
PyUnit module-level clause:

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

Hope that answers the question.

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] Converting Python's test suite to PyUnit?

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

I'm just starting to use the unittest module to create some tests for my own
code. I started by gettting the rewritten python tests from the Python CVS
to use as role models. I notice that they make use of
test_support.run_unittest(). The test_support module is not on the default
Python Path and doesn't seem to really be part of the unit testing
framework.

So, should I not be using test_support for my own tests? Is there a simple
equivalent that would allow me to look at the python tests (such as
test_time.py and test_pprint.py) yet understand how I should run the tests
if they were part of my own code?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Fred L.
Drake, Jr.
Sent: Thursday, May 17, 2001 10:30 AM
To: Steve Purcell
Cc: pyu...@li...
Subject: Re: [Pyunit-interest] Converting Python's test suite to PyUnit?

Steve Purcell writes:
 > Some of the Python 2.1 standard library unit tests are now written using
 > PyUnit (test_fnmatch.py, for example).

  Specifically:

        test_fnmatch
        test_iter
        test_pprint
        test_traceback
        test_weakref

  I've made it a task for myself to write a test for sgmllib as well;
that will be PyUnit-based.

 <snip>

Re: [Pyunit-interest] Multiple Check methods issue

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

[i tangled with this exact same thing recently]

By design, there should be one test per testcase instance.  That is, 
each test case is designed to be 100% standalone.

I ran into the same problem and did this:

     def check_100_PerformAllInOrderTests(self):
         """Perform all order dependent tests as single atomic operation 
against single instance of TestCase."""
         inorderCases = getTestCaseNames(self.__class__, "inorder", )
         for aCase in inorderCases:
             self.__class__.__dict__[aCase](self)

     def inorder_100_CreateSession(self):
	....

     def inorder_101_TestMissingNameSubmission(self):
	....

     def inorder_102_TestTooLongNameSubmission(self):
	....

... etc ....


I always put #s in my test method names out of habit.  Makes life easier 
when the developers can refer to "Test ####" as opposed to yelling names 
back and forth while pair programming.

b.bum


On Friday, June 8, 2001, at 05:06 PM, Keith, David wrote:

>
> Is there any way to have multiple check_ methods be invoked without a 
> new TestCase class being created?  For example:
>
> class CadMain_Model (unittest.TestCase):
>
>    
> #---------------------------------------------------------------------------
>    def __init__ (self, methodName='runTest'):
>       print "model test ctor"
>       unittest.TestCase.__init__ (self, methodName)
>
>    
> #---------------------------------------------------------------------------
>    def setUp (self):
>       "my setup code goes here"
>
>    
> #---------------------------------------------------------------------------
>    def check_test1 (self):
>       "my first test"
>
>    
> #---------------------------------------------------------------------------
>    def check_test2 (self):
>       "my second test"
>
>    ... more checks ...
>
> def allTests ():
>    allSuites = unittest.TestSuite()
>    allSuites.addTest(unittest.makeSuite(CadMain_Model, 'check'))
>    return allSuites
>
> suite = allTests()
> runner = unittest.TextTestRunner()
> runner.run (suite)
>
> The CadMain_Model class is instantiated for check_test1() and then 
> again for check_test2.  I'd like to have the class instantiated and the 
> setUp() code run followed by all the check_* methods being called 
> (without a new instance and setup)?
>
> Any way to do that short of moving my setUp() code to the module level 
> (which I'd rather not do)?
>
>
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> http://lists.sourceforge.net/lists/listinfo/pyunit-interest

[Pyunit-interest] Multiple Check methods issue

[Keith, D. <dc...@it...>]

Is there any way to have multiple check_ methods be invoked without a new TestCase class being created?  For example:

class CadMain_Model (unittest.TestCase):

   #---------------------------------------------------------------------------
   def __init__ (self, methodName='runTest'):
      print "model test ctor"
      unittest.TestCase.__init__ (self, methodName)

   #---------------------------------------------------------------------------
   def setUp (self):
      "my setup code goes here"

   #---------------------------------------------------------------------------
   def check_test1 (self):
      "my first test"

   #---------------------------------------------------------------------------
   def check_test2 (self):
      "my second test"

   ... more checks ...

def allTests ():
   allSuites = unittest.TestSuite()
   allSuites.addTest(unittest.makeSuite(CadMain_Model, 'check'))
   return allSuites

suite = allTests()
runner = unittest.TextTestRunner()
runner.run (suite)

The CadMain_Model class is instantiated for check_test1() and then again for check_test2.  I'd like to have the class instantiated and the setUp() code run followed by all the check_* methods being called (without a new instance and setup)?

Any way to do that short of moving my setUp() code to the module level (which I'd rather not do)?

[Pyunit-interest] Python regression tests moving to PyUnit

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

  I've spent a little time yesterday and today moving more of the
Python regression tests to PyUnit -- there should be a better base of
examples for others to follow.  If anyone wants to spend a little time
on this, feel free to do so.  If you don't have checkin privs for
Python, feel free to submit patches to me on SourceForge:

    http://sourceforge.net/tracker/?group_id=5470&atid=305470


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

Re: [Pyunit-interest] Converting Python's test suite to PyUnit?

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

Steve Purcell wrote:
> 
> Fred L. Drake, Jr. wrote:
> >   Actually, I expect the best way to migrate these tests is to rework
> > the individual test_* tests to use PyUnit instead of the current
> > code.  This will be tedious but will result in a much more
> > mamanagable test package.
> 
> That would certainly be best, though it's a *big* job! You  
> might have fun getting everyone else to re-write their tests. 

Well, every finite job can be broken down in a number of 
reasonable chunks, can't it? If somebody gives me the
rights I can convert some code myself, but it might be
beneficial to have some guideline to get a consistent
test suite implementation. Maybe that's the real issue?

> I've come across a couple of pieces of code that wrap 
> doctest tests into PyUnit test cases -- they might
> be helpful for Tim's 'doctest'-based regression tests.

This sounds interesting. At ReportLab we thought about 
a couple of different situations where you want to wrap
existing tests and/or non-Python apps using PyUnit. This 
could be stuff in the if __name__ == '__main__': section 
of Python modules, but also compiled executables, Python
or not. 

If somebody has any thoughts/experience in doing this, 
please share it with us! Thanks!

Regards,

Dinu

Re: [Pyunit-interest] Converting Python's test suite to PyUnit?

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

Fred L. Drake, Jr. wrote:
>   Actually, I expect the best way to migrate these tests is to rework
> the individual test_* tests to use PyUnit instead of the current
> code.  This will be tedious but will result in a much more
> mamanagable test package.

That would certainly be best, though it's a *big* job! You might have fun
getting everyone else to re-write their tests. I've come across a couple of
pieces of code that wrap doctest tests into PyUnit test cases -- they might
be helpful for Tim's 'doctest'-based regression tests.

-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] Verbosity levels in output

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

Dinu Gherman wrote:
> Unfortunately, I can't find any piece of code that would allow
> for the verbosity keyword argument, certainly not in the 1.3.1
> or 1.2.0 distributions of PyUnit. OTOH, there seem to be a few
> classes like VerboseTextTestRunner in 1.3.1, but they aren't 
> mentioned in the HTML documentation. So, I'm a bit confused...

Okay, it's like this:

  Python's 'unittest.py' is the same as the *CVS version* of PyUnit's
  'unittest.py'. They both have one TextTestRunner class with a 'verbosity'
  keyword argument.

  PyUnit 1.3.1 has older code, with a now-obsolete 'VerboseTextTestRunner'
  and no 'verbosity' argument.

Basically, it's up to me to make a PyUnit 1.4 release from the latest CVS
sources, but for various reasons (including that I'm in China this month)
I haven't done so yet. (My apologies to anyone who is waiting on this.)

So your confusion is entirely my fault!

A previous message I sent to this list details my policy for further
development of PyUnit; so summarise, development will flow from PyUnit to the
Python std lib, and I'll keep up 1.5.2 support for the foreseeable future.

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] Converting Python's test suite to PyUnit?

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

Dinu Gherman writes:
 > does anybody consider converting Python's test suite to 
 > using assert statements and the like to make it PyUnit
 > compliant?

  Actually, the use of assert statements is specifically *not* desired
-- that doesn't work when running Python with -O.  I think all of the
tests which have been converted use the TestCase methods to detect and
report failures.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

Re: [Pyunit-interest] Converting Python's test suite to PyUnit?

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

Steve Purcell writes:
 > Some of the Python 2.1 standard library unit tests are now written using
 > PyUnit (test_fnmatch.py, for example).

  Specifically:

	test_fnmatch
	test_iter
	test_pprint
	test_traceback
	test_weakref

  I've made it a task for myself to write a test for sgmllib as well;
that will be PyUnit-based.

 > PyUnit was fitted into the existing test script scheme in order to achieve
 > this; to convert all existing regression tests to fit PyUnit was obviously
 > considered too large a task.

  I don't think the specific fit is very comfortable.  I need to write
a proposable about how it "should" be done.

 > I've never tried to solve that particular problem, but here are my thoughts
 > after a few minutes spent looking at the Python test suite code. Each
 > 'test_*.py' file in the Python test suite is really a TestSuite in the
 > PyUnit sense. However, the set-up code in those files varies a great deal,
 > so I imagine that splitting up the files into several TestCases would be

  Actually, I expect the best way to migrate these tests is to rework
the individual test_* tests to use PyUnit instead of the current
code.  This will be tedious but will result in a much more
mamanagable test package.

 > unfeasible; the easiest translation to PyUnit would be to write a TestCase
 > subclass that would execfile() a 'test_*.py' script. Any raised Exceptions
 > would be interpreted according to the logic in Lib/test/regrtest.py; they
 > would either be re-raised as PyUnit 'errors' or translated into calls to
 > 'fail()' where necessary.

  This would certainly be easiest, but it doesn't seem very valuable.


-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

[Pyunit-interest] Verbosity levels in output

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

Steve, 

thanks for your previous reply! Now for something different...

In the Python CVS tree I find in test_support.py the following 
snippet:

  def run_unittest(testclass):
      """Run tests from a unittest.TestCase-derived class."""
      if verbose:
          runner = unittest.TextTestRunner(sys.stdout, verbosity=2)
      else:
          runner = BasicTestRunner()
      [...]

Unfortunately, I can't find any piece of code that would allow
for the verbosity keyword argument, certainly not in the 1.3.1
or 1.2.0 distributions of PyUnit. OTOH, there seem to be a few
classes like VerboseTextTestRunner in 1.3.1, but they aren't 
mentioned in the HTML documentation. So, I'm a bit confused...

In general, what I'd like to have is an adjustable verbosity
level as shown in the code snippet above, that would, e.g., 
allow to suppress or not printing (the first line of) the doc 
strings of the test functions.

Oh, now I see that the Python CVS tree has its own unittest.py 
module, that *does* specify this verbosity argument. How comes 
then, this is not in the 1.3.1 distribution? Is it going to be 
added in the next one an when will that be? I'm sure there 
won't be two different versions of PyUnit, one inside and one 
outside of the Python distro... isn't it?

Thanks,

Dinu

Re: [Pyunit-interest] Converting Python's test suite to PyUnit?

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

Dinu Gherman wrote:
> does anybody consider converting Python's test suite to 
> using assert statements and the like to make it PyUnit
> compliant?

Some of the Python 2.1 standard library unit tests are now written using
PyUnit (test_fnmatch.py, for example).

PyUnit was fitted into the existing test script scheme in order to achieve
this; to convert all existing regression tests to fit PyUnit was obviously
considered too large a task.

I hope that over time PyUnit will be used more and more in the standard
test suite.

> The background to this question is that I'm wondering 
> how to port 'legacy' tests into a format that allows to
> include them without much reediting into an existing
> PyUnit test suite? (A 'legacy test' could be any code
> writing 'results' to stdout or a file, not necessarily
> nicely formatted.)

Presumably your legacy tests run inside a framework of some sort? Then you
need to write a unittest.TestCase subclass that simulates how the
legacy framework initialises and runs a single legacy test. If the legacy
test fails, call 'fail()'.

> I know PyUnit's online documentation mentions the class
> FunctionTestCase here:
> 
>   http://pyunit.sourceforge.net/pyunit.html#TESTFUNC
> 
> but it still assumes that the wrapped function uses the 
> assert statement to determine the test's result. 

Indeed. I think FunctionTestCase is probably of limited use, other than
as an example of how to subclass TestCase in a potentially helpful way.

> To me that's only fair, and I wouldn't expect a truly 
> generic solution (OTOH, Python's current test suite 
> seems to have one, isn't it?), but from quickly looking 
> at the Python test suite I wonder how somebody would 
> wrap *that* into the "new cloth" (especially as it seems 
> to fit my 'definition' above of legacy test code)?

I've never tried to solve that particular problem, but here are my thoughts
after a few minutes spent looking at the Python test suite code. Each
'test_*.py' file in the Python test suite is really a TestSuite in the
PyUnit sense. However, the set-up code in those files varies a great deal,
so I imagine that splitting up the files into several TestCases would be
unfeasible; the easiest translation to PyUnit would be to write a TestCase
subclass that would execfile() a 'test_*.py' script. Any raised Exceptions
would be interpreted according to the logic in Lib/test/regrtest.py; they
would either be re-raised as PyUnit 'errors' or translated into calls to
'fail()' where necessary.

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] Converting Python's test suite to PyUnit?

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

Hello,

does anybody consider converting Python's test suite to 
using assert statements and the like to make it PyUnit
compliant?

The background to this question is that I'm wondering 
how to port 'legacy' tests into a format that allows to
include them without much reediting into an existing
PyUnit test suite? (A 'legacy test' could be any code
writing 'results' to stdout or a file, not necessarily
nicely formatted.)

I know PyUnit's online documentation mentions the class
FunctionTestCase here:

  http://pyunit.sourceforge.net/pyunit.html#TESTFUNC

but it still assumes that the wrapped function uses the 
assert statement to determine the test's result. 

To me that's only fair, and I wouldn't expect a truly 
generic solution (OTOH, Python's current test suite 
seems to have one, isn't it?), but from quickly looking 
at the Python test suite I wonder how somebody would 
wrap *that* into the "new cloth" (especially as it seems 
to fit my 'definition' above of legacy test code)?

Regards,

Dinu