Overview |
Enter ./browser.py or (./browser.py
-vim). You'l see a window with three panels. On top
is a tree containing the test suites available in the
current and sub folders. In the middle is a progress bar,
which will soon turn green. On the bottom is a sickly
yellow list box, where errors may appear.
Tap Enter, or Double Click on any
node.
The Browser will traverse the tree, from top to bottom
as shown, in alpha order, running each test, and
incrementing the Cyan Bar for each one. If the bar
reaches its goal Cyan, it turns Green.
To raise Vim or Idle at a file or
function, click on its entry in the Tree, then click the
second mouse button. This raises a Context Menu
containing an option to edit your test code, or (if it's
named correctly) to edit your source code.
If your code reports an error, you can click on any
line in the error list in the format ' File
"path/file.py", line 123...' or
'path/file.py:123: ...',
the Browser will extract the file name and line number,
and surf your editor to that line.
If you change code and hit Save (from any editor, not
just Vim,) the Browser detects the file change, and
re-runs the selected tests.
That's it. You now have completely incremental One
Button Testing from any editor, and One Button Error
Navigation for Vim. The editors Kate and Idle are in
the works.
On user-friendly desktops, if you use Alt+Tab
to switch between the Browser and your editor, you can
approach mouse-free development. But I'm unsure what to
do on Macintosh desktops...
|
Command Line Arguments |
Start with python browser.py to use the
current folder. The -- parameters must come first.
--Idle (The default.) Invoke Idle as
the integrated editor. --Kate Invoke the current CVS drop of
Kate (found
in kdebase) as the "integrated" editor. --vim Invoke version > 6.2 of Vim as the "integrated" editor. --Verbose Report files rejected because
we could not find their test suites. files... The relative paths to
individual files
containing test suites. Our behavior if they do not contain test
cases or suites is undefined folders... (The default is a
dot . .) The
relative folders we should search weepthe tips paths to individual files
containing test suites. Our behavior if they do not contain test
cases or suites is undefined globs... A Unix-style shell
like BASH will expand *.py into a list of local files. But if you
"escape" the star, such as "*.py" with quotes, .
Windows-style shells pass all stars, such as *.py, in unaltered.
Examples (bash dialect):
./browser.py . \*.py # The same as the default
settings.
./browser.py . test\*.py # Presents all files
in the current and sub folders that start with "test".
./browser.py --kate kozmik \*frog.py # Presents all
files in and below a folder called kozmik that
end with "frog". Kate is the bound editor.
./browser.py `find kozmik -name \*frog.py` #
ibid.
./browser.py Debug.py test_Debug.py # This only
loads test_Debug.py because the other file has
no TestCases.
|
Features |
-
<all> Double-click this, or
select it and tap Enter, or change a file, to run every
test in every folder. . (dot) Double-click this, or
select it and tap Enter, to run every test in the current
folder, but not its sub-folders. Arrow Keys If the Tree area of the
main window has the keyboard focus, then...
Down select the prior visible
item Left if the current node's
expanded it collapses, else select the prior visible
item Right if the current node's
collapsed it expands, else select the next visible
item Up select the next visible
item
Auto
Test When you save any file the PyUnit
Test Browser is "aware" of, it will run the currently
selected test set. PUB is "aware" of any python file in
or below the current folder with the word "test" in its
name. Files in folders below the current one must have
an __init__.py file (though this needn't have
contents). PUB abandons its depth search when it
encounters a folder without an __init__.py
file, so folders below this one will not be searched.
See also Reload. Cyan
Bar At test time when the
progress bar starts it's not qualified to be green yet,
so it appears
cyan.
As the bar progresses it displays the percent finished
according to the total selected test count. (This implies
the progress bar only progresses smoothly if you have
lots of very small tests.)
Debug.db(x) A trace
function. It evaluates x (natch), but then
prints to stderr the file name, line number,
stringification of x (in Python that's a
real picnic!), and the representation
of its value. Because stderr routes into the
error list, and db writes in G++ diagnostic
format, you can click on the debug trace and navigate
your least favorite editor to its location in the
source. Green Bar
If the selected tests
execute to their natural end without test failures or errors,
greenrewards
you. grep
Tap F9. A text entry field appears. Type into it the text
you want to search for, and tap Enter. PUB will search the currently
selected file(s), displaying all hits in the output list. Clicking on a
hit will raise its file and line in an editor.
Supported
on platforms where grep -Hn works. sys.stderr This redirects
into the error list at test time. If you write a file
name and line number in either G++ diagnostic
format Orange Bar If any of the
self.assert* methods report failure, the progress bar
at that point turns
orange,
and stays orange until the end or a Red Bar condition
appears. Note computers generally do a sucky orange
color... PyCheck
If you have PyChecker installed, F7 will check your test,
and F8 sniffs the code. Warnings appear in the OutputList,
so if you click on them PUB will raise their source locations
in your favorite editor Reload PUB runs
in only one Python interpreter process. At
Auto Test time, it must exchange
its current image of your module for your new one. It calls
Python's reload function to try to do this. But much
of the old image will still be in memory. Threads,
singletons, circular references and other shenanigans may
cause false test failures.
An out-of-process test runner is technically possible, but a bore.
-
-
|