This is PyUnitTestBrowser testing itself:

	http://flea.sourceforge.net/TestBrowserScreenShot.gif

"Intwiguing!" -- Baby Bear

''We are testing that the test runner can test a failing test and turn the green bar orange. This self-referential sentence compares to the mental difficulties testing testors with self-referential tests. And this sentence advises you to send mail to DouglasHofstadter that discusses testing testors with themselves by referring to itself, which he'd enjoy.''

This test rig automatically triggers a test of the currently selected item when you save your source. Hence it provides OneButtonTesting for any editor.

If your editors are Vim or Idle, you can navigate to any test, any correctly-named source, or any file and line in the error list with a click. This provides One Button Error Navigation.

Until I invite Steve Purcell to add this as a Contrib to PythonUnit, it lurks here:

	http://flea.sourceforge.net/browser006.zip

Version 004 included >all< of the command line suggestions received so far.

Version 005 bonds with PyChecker.

Version 006 bonds with grep.

The documentation is here:

	http://flea.sourceforge.net/BrowseMe.html

If you run it with Vim, add an imap and a map under a function key that saves all. This way you don't need to type <esc>:w as your muscle memory demands. (You may not have noticed that's ''not one button!'')

PyChecker is a "lint" for python. Click on a file in the tree, tap <F7> or <F8>, and PyChecker (if installed) will lint your test source or production source, respectively. Errors appear in the output list, and of course if you select them an editor will pop up with the cursor on the suspicious line.

Have fun! Bio-patches & suggestions with technical backing preferred, at mailto:phlip_cpp@yahoo.com

--PhlIp

----

'''Tested on:'''
	* Mandrake Linux 8+
	* Python 2.2 and 2.1
	* Windows NT with Python2.2
	* PythonMegawidgets 0.8.5 (''how modest of them to give such a fine package a version number <1''). Grab it from http://pmw.sourceforge.net/.

'''Do List:'''
	* Permit browser.py to be on the python path instead of in the current directory. The very aggressive module re-import system breaks relocatability.
	* make the Grep field a "MemoryEntry" - where it remembers previous commands in a drop down
	* put import syntax errors into the output list - not a Tkinter crash window
	* small time delay before import so we know the file flushed out
	* Preserve and restore the screen geometry
	* Bond with Python's debugging systems
	* Make the ditzy trace list box accept a D''''''oubleClick to raise an error
	* Publish how the maybeMainloop system works
	* Port to pygtk
	* Port to wxPython
	* Port to Ruby

'''Done List:'''
	* Specify the pattern to match test files, test_\*.py, on the command line
	* Specify individual test files, with paths, on the command line
	* Specify test folders on the command line
	* db() routes into the error list
	* Find TestCase''''''s by any means necessary
	* Test under MsWindows. One dumb os.sep bug fixed!
	* Added (a very untested) link to Python's Idle editor
	* Test under Python2.1 and clean up hyperactive assertions

----

''A truly beautiful piece of work by Phlip. Highly recommended.'' -- PeterMerel

PhlIp, I've been refactoring stuff for the last couple hours. A friend suggested that refactoring code that you don't understand is a great way to understand it. It doesn't matter if you make the code
worse as you go. What the hey, just change it back once you understand better.

I set up my screen as follows. A shell window on the left, with a little space underneath the window near the bottom of the screen. In that space, pytest's green bar. (The shell window is on top of the pytest window, and the bottom of the pytest window is off the bottom of the screen, so only the green bar is visible.) A vi window on the right.

''Ben only used the GreenBar, and kept the tree and error list out of the way. Because PUB routes errors to both the console and the error list, he watched both program output and errors flow in the "shell window" console. In other words, Ben built an IDE out of Vim (imagine that!), a shell window, and a green bar. PlugAndPlay.''

I just plowed through the test code, changing anything I didn't like, and immediately hitting :w as I always do. The bar went to cyan and back to green. Occasionally when I'd introduce a syntax error, the bar would go orange, and I'd fix it. I got going to an amazingly fast pace, making lots of tiny changes and constantly verifying that they were right. I could zip along and start the next tiny change with only the corner of my eye on the bar.

Excellent. Beautiful. Efficient. Pleasant, even. Addictive.

-- BenKovitz

----

''Now if only it got notified by the editor on file write instead of constantly polling and chewing up CPU ... probably a more civilized way to launch the thing in most editors anyway ...''

The "TestOnSave" meme should infest all test runners. However...

...if you can find a platform- language- and editor-neutral way to either...

	* send a ping from any editor to a test runner
	* sample the local folder's file list as a semaphore

...then I'd love to hear of it.

The sticky point is no TestRunner author wants to force users to use a particular editor. So all TestRunner authors invite users to solve the LastMile problem by hand, most users then devolve to a save-mouse-click-click cycle just to test.

Further, the test runner should persist in a window during edits. Hence it's always in the same configuration, and one can edit while testing (if one thinks that's wise), and one can test without directly interacting with the testor. This provides overwhelming flow benefits. Keyboard and mental focus remain in the editor until a difficult error occurs. The more one tests, the less often one will.

Until a real solution to all these conflicting requirements emerges, we poll. If you actually experience CPU slowdown due a timer which is currently set to a 1/2 second interval, either upgrade something or reduce something else.

As of the 2.6 linux kernel, linux supports iNotify, which allows programs to be notified upon filesystem events such as writing to a file.  Perhaps this would be a good way to implement this kind of thing... See: http://www-128.ibm.com/developerworks/linux/library/l-inotify.html for more info.  The only problem with this is that it's not cross platform.

''I believe the right thing then is for the testrunner to listen on a public pipe. If you want a file or routine tested, you just throw its name down the pipe. Maybe acquire names from CVS too ... then all it wants is to define levels of diagnostic a la StarTrek. Seriously, TestRunnerIsToCodeAsBrowserIsToText ... isn't that what the SmallTalk''''''ers have been trying to tell us all these years?''

I implemented something like this in RubyTk and DistributedRuby -- I split it into two processes so the GUI only listened to the results from the fresh clean interpreter each time it was invoked, didn't have to worry about the slate not being clean. Didn't have PhlIp's extra touches, though, for sure. But it'd be a short step to make such a beast language-independent -- care to specify a TestResultXmlSchema so xUnits can talk the same language to their GUIs? (which would simplify running PHP tests a ''lot''!) -- RyanPlatte