[vtk-developers] Rudimentary testing of vtkpython [long].

[Prabhu Ramachandran]

hi,

Warning: another long message.  Might be useful to some though. :)

I dont know how useful this will be at all but today afternoon while
cleaning up some of the vtkPipeline browser code I cooked up a simple
test suite for the vtkMethodParser that I use.  It basically takes all
the vtk objects that vtkpython provides and tries to run the parser on
it.  Since there is no pipeline there are lots of error messages.  I
use it to test the parser by seeing if I get any exceptions.  As a
side effect I think it could be used as a quick and dirty test for the
python bindings.  The entire test takes only aobut 15 seconds to run
on *all* the classes.  Multiply that by two to take care of first time
loading of vtkpython and you have a les than 1 minute test that
atleast instantiates almost all vtkpython objects and calls almost
every possible method in it.  It certainly will call *all* the methods
of the type SetA/GetA, SetAToB, On/Off and all the possible GetA()
methods for each object.

Basically it does the following:

p = vtkMethodParser.VtkMethodParser()
for obj_name in dir(vtkpython):
    if check_if_vtk_obj(obj_name):
       obj = eval('vtkpython.%s()'%obj_name)
       p.parse_methods(obj)

its not so trivial but thats the main idea.

Here is a sample run:

  $ python test_trace.py

  **************************************************
  Not testing the following objects since they cause segfaults.
  ['vtkLODProp3D', 'vtkPropAssembly', 'vtkRayCaster', 'vtkViewRays']
  **************************************************
  Testing vtk3DSImporter
  ok
  Testing vtkActor
  ok
  ....

  Testing vtkArrayCalculator
  ERROR: In vtkDataSetToDataSetFilter.cxx, line 91
  vtkArrayCalculator (0x818ced0): Abstract filters require input to be
  set before output can be retrieved
  ...
  Testing vtkCreateKitModuleName
  **************************************************
  Not testing vtkpython.vtkCreateKitModuleName().  Not a vtk object.
  **************************************************
  ...
  Parsed all VTK Python classes.  A total of 545 classes were parseable.
  $

I found that the following problems occur:

If I test any of these:

['vtkLODProp3D', 'vtkPropAssembly', 'vtkRayCaster', 'vtkViewRays']

I get segfaults so I trap them.  Its pretty trivial to test where the
segfault actually occurs if you use the test_parser like so:

$ python -c "import test_parser;test_parser.test_obj('vtkLODProp3D')"
VtkMethodParser:: parse_methods()
VtkMethodParser:: _initialize_methods()
VtkDirMethodParser:: initialize_methods ()
VtkDirMethodParser:: parse_methods() : initialized methods
VtkDirMethodParser:: clean_get_set()
VtkDirMethodParser:: clean_state_methods()
VtkDirMethodParser:: clean_get_methods()
Segmentation fault
$

So I add a print statement in clean_get_methods() and I find that the
segfault occurs in the GetPickLODID function.  Maybe this isn't an
error and maybe since there is no input this fails but is a segfault a
good thing?  

Also, I get bad window errors when I test anything that
IsA('vtkImageWindow') or IsA('vtkRenderWindow').  It is obvious why
this happens so I simply dont test these (sub)classes.

My point is its easy to do simple testing using this.  Currently the
method parser is used to make a Tkinter based gui configurator
(http://mayavi.sf.net/vtkPipeline/) but it can be modified to do
specific things for testing vtkPython itself.  It also makes it pretty
easy to see pretty much all the obsolete messages.

So is anyone interested in this?  It doesnt require the all of the
vtkPipeline stuff - just two files!  If this does raise interest we
can work on something.

Meanwhile, while I am at it here are the 'segfaulters' in the current
VTK 4.0 tree.

	  vtkLODProp3D in GetPickLODID

	  vtkPropAssembly in GetBounds

	  vtkRayCaster in GetParallelIncrements

	  vtkViewRays also in GetParallelIncrements

Actually, that isnt so bad considering that 545 other classes behaved
so well inspite of a pretty silly test.

prabhu

-- 
There are always alternatives.
		-- Spock, "The Galileo Seven", stardate 2822.3