pyunit-interest

Re: [Pyunit-interest] ANN: Pycotin 0.1, a Python Cocoa Test Interface for PyUnit

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

Phlip <ppl...@om...>:

> I'm not a cocoa-nut, so I can't try it...

Hi,

I've uploaded an MPEG-4 Quicktime movie that will show
everything Pycotine can do right now! ;-) (785 KB)

  http://python.net/~gherman/projects/pycotine/sample.mov


> ...but may I ask if it has these features?
> 
>  - triggers tests when you save your file
>  - incremental test selection (all or a batch or one)
>  - navigates your editor to a test method, source method, 
>    or error location

There is no integration yet to any editor whatsoever.
Hence, none of these features are present!


> I ask because my Pmw/Tkinter test browser has these features...
> 
> 	http://c2.com/cgi/wiki?PyUnitTestBrowser

Looks nice, I'll look deeper into it.

Thanks!

Dinu

Re: [Pyunit-interest] ANN: Pycotin 0.1, a Python Cocoa Test Interface for PyUnit

[Phlip <ppl...@om...>]

Dinu Gherman sez:

> for those who care, I've just released "Pycotin", a native
> Cocoa GUI to PyUnit testing on OS X. It's been just born,
> but looks verys promising. Please find the code plus two
> screenshots in my Starship Python cabin:

>   http://python.net/~gherman/#Pycotin

I'm not a cocoa-nut, so I can't try it...

...but may I ask if it has these features?

 - triggers tests when you save your file

 - incremental test selection (all or a batch or one)

 - navigates your editor to a test method, source method, or error location

I ask because my Pmw/Tkinter test browser has these features...

	http://c2.com/cgi/wiki?PyUnitTestBrowser

...and they represent a very tight coding cycle I call OneButtonTesting. If 
Pycotin does not yet have these features, please feel free to raid 
PyUnitTestBrowser for sample code. It triggers tests from any editor (under 
the wild assumption that all of them can save files), and it can navigate 
Idle, Kate, or Vim.

-- 
  Phlip
        http://www.greencheese.org/PeaceAndCalm
"We may eventually come to realize that chastity is no more a virtue
than malnutrition."  -- Alexander Comfort

Re: [Pyunit-interest] ANN: Pycotin 0.1, a Python Cocoa Test Interface for PyUnit

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

Steve Purcell <ste...@ya...>:

> Great!
> 
> Now I have to find a Mac on which to try it out...

It was long on my todo list... 

One interesting aspect about the Python code here is that 
I'm using my own subclass of TestResult, that continuously 
writes status information to a file (which is then contin-
uously displayed in the GUI). 

This could be a way of letting other non-Python GUIs do 
the same thing and might be worth being generalised, some-
how, but I've actually never seen the PyUnit Tkinter GUI 
running.

Regards,

Dinu

Re: [Pyunit-interest] ANN: Pycotin 0.1, a Python Cocoa Test Interface for PyUnit

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

Great!

Now I have to find a Mac on which to try it out...

-Steve


Dinu Gherman wrote:
> for those who care, I've just released "Pycotin", a native
> Cocoa GUI to PyUnit testing on OS X. It's been just born,
> but looks verys promising. Please find the code plus two
> screenshots in my Starship Python cabin:
> 
>   http://python.net/~gherman/#Pycotin
> 
> Regards,
> 
> Dinu

[Pyunit-interest] ANN: Pycotin 0.1, a Python Cocoa Test Interface for PyUnit

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

Sorry for the typo... I think, I should really only use 
the abbreviated "sf.net"... :-/

Dinu


----- Forwarded message from <gh...@da...> -----
Date: Fri, 19 Jul 2002 11:20:51 +0200 (CEST)
From: Dinu Gherman <gh...@da...>
Reply-To: Dinu Gherman <gh...@da...>
Subject: ANN: Pycotin 0.1, a Python Cocoa Test Interface for PyUnit
To: pyt...@py...,pyu...@li...

Hi,

for those who care, I've just released "Pycotin", a native
Cocoa GUI to PyUnit testing on OS X. It's been just born,
but looks verys promising. Please find the code plus two
screenshots in my Starship Python cabin:

  http://python.net/~gherman/#Pycotin

Regards,

Dinu


PS: From the README:

Pycotin 0.1

Pycotin (Python Cocoa Test Interface) is a Cocoa GUI to
Steve Purcell's PyUnit test framework (1) on Mac OS X.
For now, its user interface is very much designed after
the existing Tkinter one (2), but that might slightly
change again.

Pycotin was developped from its author's personal frust-
ration with running (or rather not running) Tkinter on
Mac OS X as the only existing GUI for PyUnit. While it
might well be possible to make Tkinter run on this plat-
form, it was probably easier to write this little tool...

Basically, with Pycotin you can "open" Python files (with
extension ".py") and execute testsuites created in these
files with the "unittest" module of the Python 2.0 stan-
dard library. Right now Pycotin trys to import a function
named "suite()" or "makeSuite()" from an opened Python
module which it assumes to build and return a testsuite.
This can clearly be made much smarter, but also depends
on your habits as testsuite designer.

The test files in samples/ were shamelessly copied from
Steve Purcell's own original test cases for PyUnit 1.4.1
(just skipping the Tkinter ones for obvious reasons).
I added only one new file, "listtestsfail.py" which shows
a failing test, too.

Pycotin is in early alpha phase! Be not surprised to see
some buglets when dealing with paths containing blanks!

----- End forwarded message -----

Re: [Pyunit-interest] Feature Request: Cleanup Registry

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

Hi Jim,

Sorry for the slow response.

Interesting suggestion. I wonder about a couple of things.

Firstly, not every test would require every cleanup function to be
called, so calling every function after every test seems a high
price to pay for convenience. Imagine running 10,000 tests,
where each block of 100 requires a single (but different) clean-up
function: that's 1,000,000 cleanup function invocations instead
of 10,000.

Secondly, I'm nervous about the notion of adding clean-up functions
to the clean-up registry from 'outside' testing code, as in the
example you provided. What if the test module is imported multiple
times, e.g. by the unittest GUI? -- then, clean-up functions might
be registered multiple times, presumably in global variables in
the unittest module.

Cleaning-up of component registries is to be done after every
Zope test, as I understand things. In that case, I'd think
a common base class for your Zope test cases is in order, with a
standardised 'tearDown()' that all subclasses should call if they
also implement a 'tearDown()' method. This is a safer solution, in
my opinion.

Or am I missing something?

Very best wishes,

-Steve


Jim Fulton wrote:
> Problem
> 
>   the Zope 3 project is making extensive use of PyUnit.  Zope 3 unit
>   tests often have to register components with various component
>   registries. These registrations need to be torn down after each
>   test. This became very tedious. For this reason, we've implemented a
>   cleanup registry. Any stateful global objects, like component
>   registries register functions with this cleanup registry. Test
>   classes provide tearDown methods that call a method on the cleanup
>   registry, which calls all the registered functions.  This is an
>   extremely useful pattern that might be beneficial to other
>   projects. Further, it would be nice if test classes didn't have to
>   provide a tear-down method that just called the cleanup registry (or
>   mix-in a class that provided such a tearDown.
> 
> Proposal
> 
>   Add a cleanup registry to the unittest module.  The unittest module
>   would provide an additional function, addCleanUp, which takes a
>   callable object to be called without arguments after running each
>   unit test. After each test, and after running the test class's
>   tearDown method, each registered cleanup callable will be called.
> 
>   Suppose there was an application module with a global dictionary
>   that was manipulated by application routines:
> 
>      TheData = {}
> 
>   The module would register the clear method of this dictionary with
>   unittest.addCleanUp to make sure the dictionary was reinitialized
>   after each test:
> 
>      import unittest
>      unittest.addCleanUp(TheData.clear)
> 
> I'd be happy to provide a patch.
> 
> Jim

Re: [Pyunit-interest] Feature Request: Make TestCase a new-style class

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

Hi again Jim,

Excellent suggestion. I shall make it so.

Best wishes,

-Steve


Jim Fulton wrote:
> 
> I typically write unit test base classes for interfaces and then
> mix these base classes into test cases for implementations of the
> interfaces. I'd like to use the Python 2.2 super function to make
> sure that all of my setUp and tearDown methods get called, but I can't
> do that because TestCase is a classic class.
> 
> I propose adding:
> 
> __metaclass__ = type
> 
> to the top of unittest.py to make sure that all of the unittest
> classes are new-style classes for Python 2.2 and higher.
> 
> Jim

Re: [Pyunit-interest] Feature Request: Cleanup Registry

[Ype K. <yk...@xs...>]

Jim,

you wrote:

>My request and yours are not all that similar. I'd still like a response
>to *my* request.
>
>Jim
>


you wrote earlier:
>Problem
>
>  the Zope 3 project is making extensive use of PyUnit.  Zope 3 unit
>  tests often have to register components with various component
>  registries. These registrations need to be torn down after each
>  test. This became very tedious. For this reason, we've implemented a
>  cleanup registry. Any stateful global objects, like component
>  registries register functions with this cleanup registry. Test
>  classes provide tearDown methods that call a method on the cleanup
>  registry, which calls all the registered functions.  This is an
>  extremely useful pattern that might be beneficial to other
>  projects. Further, it would be nice if test classes didn't have to
>  provide a tear-down method that just called the cleanup registry (or
>  mix-in a class that provided such a tearDown.

You're right, it's in the tearDown() of a test and not in the tearDown()
of a test suite.

In case cleaning the registry is your only tearDown() functionality
with a mix-in you end up defining:


class RegistryCleaner:
    def tearDown(self): theRegistry.cleanup()

class someZope3TestCase( RegistryCleaner, unittest.testcase):
    ....


In case mixing in is too tedious you can use straight inheritance:


class RegistryCleaningTestCase( unittest.testcase):
    def tearDown(self): theRegistry.cleanup()
    # No test...() methods here.
    # Evt. move out of module scope to prevent searching for test...() methods.

class someZope3TestCase( RegistryCleaningTestCase):
    # test... methods here


When you need more tearDown() functionality depending on the actual test case
class, you can call back:


class RegistryCleaner:
    def tearDown(self):
        theRegistry.cleanup()
        self.tearDown2() # if hasattr(self, 'tearDown2')


and define tearDown2() instead of tearDown() in someZope3TestCase.

Here it would be nice to be able to call all tearDown() methods in
a multiple inheritance hierarchy, but I don't know how to do that in python.

I don't think any of this is tedious, and I guess even more compact
ways are possible.

Have fun,
Ype

-- 

Re: [Pyunit-interest] Feature Request: Cleanup Registry

[Jim F. <ji...@zo...>]

My request and yours are not all that similar. I'd still like a response
to *my* request.

Jim

-- 
Jim Fulton           mailto:ji...@zo...       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

Re: [Pyunit-interest] Feature Request: Cleanup Registry

[Ype K. <yk...@xs...>]

Jim,

I made a similar proposal some time ago. Below is the reply
of Steve Purcell. He convinced me.

Jim wrote:
>Problem
>
>  the Zope 3 project is making extensive use of PyUnit.  Zope 3 unit
>  tests often have to register components with various component
>  registries. These registrations need to be torn down after each
>  test. This became very tedious. For this reason, we've implemented a
>  cleanup registry. Any stateful global objects, like component
>  registries register functions with this cleanup registry. Test
>  classes provide tearDown methods that call a method on the cleanup
>  registry, which calls all the registered functions.  This is an
>  extremely useful pattern that might be beneficial to other
>  projects. Further, it would be nice if test classes didn't have to
>  provide a tear-down method that just called the cleanup registry (or
>  mix-in a class that provided such a tearDown.
>
>Proposal
>
>  Add a cleanup registry to the unittest module.  The unittest module
>  would provide an additional function, addCleanUp, which takes a
>  callable object to be called without arguments after running each
>  unit test. After each test, and after running the test class's
>  tearDown method, each registered cleanup callable will be called.
>
>  Suppose there was an application module with a global dictionary
>  that was manipulated by application routines:
>
>     TheData = {}
>
>  The module would register the clear method of this dictionary with
>  unittest.addCleanUp to make sure the dictionary was reinitialized
>  after each test:
>
>     import unittest
>     unittest.addCleanUp(TheData.clear)
>
>I'd be happy to provide a patch.


This is Steve's reply to my post:

Date: Sun, 23 Sep 2001 13:38:09 +0200
From: Steve Purcell <ste...@ya...>
To: Ype Kingma <yk...@xs...>
Cc: pyu...@li...

Subject: Re: [Pyunit-interest] setup/teardown for a TestSuite


Hi Ype,

Previous discussion on this list of this topic may be hidden behind obscure
subject lines; you're not the first to suggest a setUp and tearDown for
TestSuite.

However, this defeats one of the central ideas of the framework, which is
that each test should be able to run either in isolation or in arbitrary
combination with other tests. That is, each test case should provide for the
setting up and tidying up of the environment in which it runs.

Test cases need not even run as part of a suite:

   class MyTestCase(unittest.TestCase):
       def testSomething(self): pass

   unittest.TextTestRunner().run(MyTestCase())

If the system must be placed into some state before a number of tests are
run, and if that state is certain to be unaffected by the tests, there are
a couple of strategies.

Firstly, each test case could be given a 'setUp' method that lazily sets up
that state, possibly using a helper module.

Secondly, the environment could be set up before the TestRunner is invoked
(or 'unittest.main()' called).

It's worth going to some trouble to make each TestCase outwardly independent
of other code.

Best wishes,

-Steve




Ype Kingma wrote:
> Hello pyunit'ers,
>
> I recently started using unittest.py, and it serves me well.
> At some point I needed to setUp and tearDown a TestSuite.
> The pattern is:
> - bring a system into an interesting state,
> - perform some testcases on the system,
> - bring the system back into it's original state.
> This is useful when setup and/or teardown
> are non trivial and there are more than a few testcases.
>
> I checked the archives a bit but there did not seem to be
> any discussion on this.
>
> So I subclassed SetUpTestSuite from TestSuite. I added methods
> setUpSuite() and tearDownSuite(), called these from the
> __call__() method and allowed for exceptions during setup/teardown
> being reported as test errors.
>
> Having written the code I realised I could have done it by
> implementing a TestCase to execute a TestSuite.
>
> Another look at the code made me realise that it might be added
> into TestSuite without introducing too many backward incompatibilities,
> after all I guess that TestSuite isn't subclassed very often.
>
> The working code is below, comments invited, please use it
> as you see fit.
>
> Ype


--
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
GPG fingerprint: EB79 2AB1 D494 16F9 8C3B  DAC6 5341 30CE BCCA EBEA
-- 

[Pyunit-interest] Feature Request: Make TestCase a new-style class

[Jim F. <ji...@zo...>]

I typically write unit test base classes for interfaces and then
mix these base classes into test cases for implementations of the
interfaces. I'd like to use the Python 2.2 super function to make
sure that all of my setUp and tearDown methods get called, but I can't
do that because TestCase is a classic class.

I propose adding:

__metaclass__ = type

to the top of unittest.py to make sure that all of the unittest
classes are new-style classes for Python 2.2 and higher.

Jim

-- 
Jim Fulton           mailto:ji...@zo...       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

[Pyunit-interest] Feature Request: Cleanup Registry

[Jim F. <ji...@zo...>]

Problem

   the Zope 3 project is making extensive use of PyUnit.  Zope 3 unit
   tests often have to register components with various component
   registries. These registrations need to be torn down after each
   test. This became very tedious. For this reason, we've implemented a
   cleanup registry. Any stateful global objects, like component
   registries register functions with this cleanup registry. Test
   classes provide tearDown methods that call a method on the cleanup
   registry, which calls all the registered functions.  This is an
   extremely useful pattern that might be beneficial to other
   projects. Further, it would be nice if test classes didn't have to
   provide a tear-down method that just called the cleanup registry (or
   mix-in a class that provided such a tearDown.

Proposal

   Add a cleanup registry to the unittest module.  The unittest module
   would provide an additional function, addCleanUp, which takes a
   callable object to be called without arguments after running each
   unit test. After each test, and after running the test class's
   tearDown method, each registered cleanup callable will be called.

   Suppose there was an application module with a global dictionary
   that was manipulated by application routines:

      TheData = {}

   The module would register the clear method of this dictionary with
   unittest.addCleanUp to make sure the dictionary was reinitialized
   after each test:

      import unittest
      unittest.addCleanUp(TheData.clear)

I'd be happy to provide a patch.

Jim

-- 
Jim Fulton           mailto:ji...@zo...       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

[Pyunit-interest] ANN: PyUnitTestBrowser 006

[Phlip <phl...@ya...>]

<posted & mailed>

PyUnit Enthusiasts:

The latest feature is integrated grep. This means if your editor does not 
have multi-file search, we do.

        http://flea.sourceforge.net/BrowseMe.html
        http://flea.sourceforge.net/browser006.zip
        http://www.c2.com/cgi/wiki?PyUnitTestBrowser

PyUnitTestBrowser is a GUI TestRunner for PyUnit that integrates, 
round-trip, with Kate, Idle or Vim.

The ChangeLog:

        005 bonds with PyChecker
        004 arbitrarily complex command lines
        003 does not require test suites
        002 does Windows
        001 exists

-- 
  Phlip
          http://www.greencheese.org/ParodyMode
  --  Appears that VIM is internationalized...
      May I ask what's the point?               --

Re: [Pyunit-interest] ANN: PyUnitTestBrowser

[Phlip <ppl...@om...>]

Fred L. Drake, Jr. sez:

> What's wrong with shutil.rmtree() ?

What's wrong with it is I never heard of it. I'l work on this issue for a 
while and see if I eventually hear of it.

>  > The bug is 'reload(module)' often does not work.
>
> We need more information than this!  What do you mean?  Do you have a
> reproducible test case?

It's a general request for help, that Steve answered very specifically. If I 
need to reload the same way other test runners reload, then I need to ask the 
question in general to someone who has already covered that area.

His answer was to take a snapshot of all the modules loaded before the test 
runner starts testing, and then to return to this state at reload time by 
whacking every module not in the snapshot.

No further request for assistance implied.

>  > When a file changes I whack its self.myModule handle, and all the
>  > children below it in the tree and build them again. But Python's
>  > infamous
>
> Did you leave something off here?

...module import ability leaves bits of the old modules strewn around memory, 
as does its infamous garbage collection system. Objects created from old 
modules with positive reference counts remain, figuratively "next to" the 
ones created from new modules.

-- 
  Phlip
   http://www.greencheese.org/PhilosophyBrethrenThree
"Nothing is more despicable than respect based on fear."  -- Albert
Camus

Re: [Pyunit-interest] PyUnitTestBrowser

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

Phlip writes:
 > The bug is 'reload(module)' often does not work. 

We need more information than this!  What do you mean?  Do you have a
reproducible test case?

 > When a file changes I whack its self.myModule handle, and all the children 
 > below it in the tree and build them again. But Python's infamous

Did you leave something off here?

 > Does anyone know of a more aggressive reload() function out there
 > that fixes this?

We can't know this unless we know what you think is wrong with
reload().


  -Fred

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

Re: [Pyunit-interest] ANN: PyUnitTestBrowser

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

Phlip writes:
 > So I hope y'all can understand the pressure on me to write
 > os.system("rm -f " + tempFileOrDirectory) instead of the current
 > blob of portable crap to do it.
 >
 > Come to think of it, I could write a "removeForced()" function over
 > "glob.glob" and "os.path.isfile". I think I'l do that first before
 > reading this evening's bug reports (if any ;).

What's wrong with shutil.rmtree() ?


  -Fred

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

[Pyunit-interest] PyUnitTestBrowser reports from the field

[Syver E. <syv...@on...>]

This is from the Pmw error dialog. It happens after rounding up a
whole slew of files, and then trying to expand one of the files that
was loaded (other files work fine). Hmm, strange I have trouble
reproducing this error, on a second run it works fine. Could it be
timing related in any way??

(Window title: Error in background function)

Error: 1
ValueError Exception in Tk callback
  Function: <bound method TreeBox._TreeBox_Click of <TreeBox.TreeBox instance at 0x0168ACA0>> (type: <type 'instance method'>)
  Args: (<Tkinter.Event instance at 0x00A48F98>,)
  Event type: ButtonPress (type num: 4)
Traceback (innermost last):
  File "D:\devtools\Python22\lib\site-packages\Pmw\Pmw_0_8_5\lib\PmwBase.py", line 1690, in __call__
    return apply(self.func, args)
  File "d:\devtools\python22\lib\site-packages\browser\TreeBox.py", line 239, in _TreeBox_Click
    self._Expand(self._Node_ids[ItemID])
  File "d:\devtools\python22\lib\site-packages\browser\TreeBox.py", line 550, in _Expand
    self._SetMoveTag(parNode)
  File "d:\devtools\python22\lib\site-packages\browser\TreeBox.py", line 606, in _SetMoveTag
    x1,y1,x2,y2=self.coords(iline)
  File "d:\devtools\python22\lib\lib-tk\Tkinter.py", line 1927, in coords
    self.tk.splitlist(
ValueError: invalid literal for float(): 70.0

================================================
  Event contents:
    char: ??
    delta: 1
    height: 0
    keycode: 1
    keysym: ??
    keysym_num: 1
    num: 1
    send_event: 0
    serial: 623
    state: 8
    time: 11406151
    type: 4
    widget: .23575224.10587840.23637152
    width: 0
    x: 76
    x_root: 124
    y: 171
    y_root: 238

-- 

Vennlig hilsen 

Syver Enstad

Re: [Pyunit-interest] PyunitBrowser 003 on win32

[Syver E. <syv...@on...>]

Phlip <ppl...@om...> writes:
> 
> >     fileName = os.path.normpath(fileName) # fix by syver
> 
> I will add this (with the attribution ;-) the next time I'm working on
> the module.

No please, don't put my attribution there, it's just to point the way
to where I've changed things from the original source (I don't speak
diff as fluently as others around here). The last time I did that, the
comment got into the win32com sources, and it looks really silly. So
please remove the comment, Okay???


-- 

Vennlig hilsen 

Syver Enstad

Re: [Pyunit-interest] PyunitBrowser 003 on win32

[Phlip <ppl...@om...>]

Syver Enstad sez:

> I understand that the PyUnitTestBrowser is written primarily
> for use on *nix machines, and by reporting problems found when running
> under win32 I don't therefore mean that you are in anyway obligated to
> fix them. I just report them in case you are interested in knowing
> about them.

Then you misunderstand me.

I intend to ask Steve to add this to PyUnit, under a folder called 
contrib/browser. And I intend to port it to wherever Python & Tkinter go.

To do that I need to remove Pmw, and get these idiotic path issues fixed.

> When run (version 003) from the site-packages/browser directory with
> the commandline: python browser.py I experience the following errors
> in test_browser.py
> (see bottom of mail)

I have been sneakily upgrading those temporary "releases" if I improve them 
but don't add anything radical or contradict the documentation. Please try 
one of these:

	http://flea.sourceforge.net/browser003.zip
	http://flea.sourceforge.net/browser.zip

The latter is my latest bench version - the equivalent of a CVS HEAD.

> The fileNameToModuleName test case can be fixed by
> using os.sep in the construction of the test string

This has been fixed, test-first. So the tests should reveal that stoopid 
function working with a range of kinds of relative file locations. 

>     fileName = os.path.normpath(fileName) # fix by syver

I will add this (with the attribution ;-) the next time I'm working on the 
module.

>     if fileName[0] != '.':  fileName = '.' + os.sep + fileName

Yeek! You just took it off so we can put it on again! The only reason it's 
there is to hard-code the [1:] two lines down!

>     fileName = fileName[:-3]
>     moduleName = string.split(fileName, os.sep)[1:]

> The windows version of the os.path module doesn't have the samefile
> method, only on *nix and mac methinks.

Translation: It works by checking the inode; Windowz and mac don't have them 
but do have absolute jiggers built into their directory system, and the 
Python guys didn't feel like research this.

Thanks for the error traces; I'l see when I have time ;-)

-- 
  Phlip
     http://www.greencheese.org/DontPlanDesigns
"I love children, especially when they cry, for then someone takes
them away."  -- Nancy Mitford

[Pyunit-interest] PyUnitTestBrowser, my unit tests work!!!

[Syver E. <syv...@on...>]

Thanks Phlip, the UnitTest browser now locates my unittest perfectly
(just unittest.TestCase derived classes in the source files).
Very nice!

I think I will use the browser a lot from now on.
-- 

Vennlig hilsen 

Syver Enstad

[Pyunit-interest] PyunitBrowser 003 on win32

[Syver E. <syv...@on...>]

Note to Phlip: 
I understand that the PyUnitTestBrowser is written primarily
for use on *nix machines, and by reporting problems found when running
under win32 I don't therefore mean that you are in anyway obligated to
fix them. I just report them in case you are interested in knowing
about them.



When run (version 003) from the site-packages/browser directory with
the commandline: python browser.py I experience the following errors
in test_browser.py
(see bottom of mail)

The fileNameToModuleName test case can be fixed by 
using os.sep in the construction of the test string

Like this:
got = fileNameToModuleName('.'+os.sep+'yak.py')
instead of:
got = fileNameToModuleName('./yak.py')

But I think it would be better to use os.path.normpath in
(fileNameToModuleName). os.path.normpath takes away unecessary path
components too (like ./ and variations), so it's a nice tool to use in
, since windows applications generally should handle both the fwd and
the reverse slash (why does this remind of the lf/crlf problems,
aargh!!) Here's the fix for the fileNameToModuleName function:

def fileNameToModuleName(fileName):
    'TODO  is there a way in Python to avoid this drek??'

    assert fileName[-3:] == '.py'
    fileName = os.path.normpath(fileName) # fix by syver
    if fileName[0] != '.':  fileName = '.' + os.sep + fileName
    fileName = fileName[:-3]
    moduleName = string.split(fileName, os.sep)[1:]
    moduleName = string.join(moduleName, '.')
    while moduleName[0] == '.':  moduleName = moduleName[1:]
    return moduleName



The windows version of the os.path module doesn't have the samefile
method, only on *nix and mac methinks. The only help I can provide
here would be to use the relative to absolute filename functions and
then run os.path.normpath and then upper and compare the names.

try:
    os.path.samefile(bla, bla)
except AttributeError:
    # do smelly stuff here


======================================================================
FAIL: test_checkTime (test_browser.BrowserTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\devtools\Python22\Lib\site-packages\browser\test_browser.py", line 31
6, in test_checkTime
    same = os.path.samefile(file, _test_orangeHerring)
AttributeError: 'module' object has no attribute 'samefile'

======================================================================
FAIL: test_fileNameToModuleName (test_browser.BrowserTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\devtools\Python22\Lib\site-packages\browser\test_browser.py", line 39
1, in test_fileNameToModuleName
    got = fileNameToModuleName('./yak.py')
  File "browser.py", line 400, in fileNameToModuleName
    while moduleName[0] == '.':  moduleName = moduleName[1:]
IndexError: string index out of range

test_DB also fails with the following:

======================================================================
FAIL: test_db (test_Debug.DebugTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\devtools\Python22\Lib\site-packages\browser\test_Debug.py", line 34,
in test_db
    self.assertEquals(self.myOutput, exp)
  File "d:\devtools\python22\lib\unittest.py", line 286, in failUnlessEqual
    raise self.failureException, \
AssertionError: 'D:\\devtools\\Python22\\Lib\\site-packages\\browser\\test_Debug
.py:22: x = 10\nD:\\devtools\\Python22\\Lib\\site-packages\\browser\\test_Debug.
py:24: x,y = (10,11)\nD:\\devtools\\Python22\\Lib\\site-packages\\browser\\test_
Debug.py:25: x,(y) = (10,11)\n' != 'test_Debug.py:22: x = 10\ntest_Debug.py:24:
x,y = (10,11)\ntest_Debug.py:25: x,(y) = (10,11)\n'



-- 

Vennlig hilsen 

Syver Enstad

Re: [Pyunit-interest] Re: PATCH: AssertionError message

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

Phlip writes:
 > Sorry, but do back-ticks do the same as repr? I thought they did string.

They are equivalent to repr().


  -Fred

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

Re: [Pyunit-interest] Re: PATCH: AssertionError message

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

Patrick K. O'Brien wrote:
> Yes, backticks (backquotes) do the same as repr. But they a bit of a wart
> and I wouldn't encourage their use. The code above could instead be:
> 
>                   (msg or '%r != %r' % (first, second))


Not with Python 1.5.2.

-Steve

Re: [Pyunit-interest] Re: PATCH: AssertionError message

[Alexander G. <al...@in...>]

On Tue, Jun 04, 2002 at 05:31:30AM -0700, Phlip wrote:
> Sorry, but do back-ticks do the same as repr? I thought they did string.

I had the same question. Here's the relevant snippet from the docs
(section 2.3):

repr (object)
           Return a string containing a printable representation of an
           object. This is the same value yielded by conversions (reverse
           quotes).

RE: [Pyunit-interest] Re: PATCH: AssertionError message

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

[Phlip]
> >         if first != second:
> >             raise self.failureException, \
> >                   (msg or '%s != %s' % (`first`, `second`))
>
> Sorry, but do back-ticks do the same as repr? I thought they did string.

Yes, backticks (backquotes) do the same as repr. But they a bit of a wart
and I wouldn't encourage their use. The code above could instead be:

                  (msg or '%r != %r' % (first, second))

---
Patrick K. O'Brien
Orbtech