[Bf-committers] Re: Automated test harness

[Ton Roosendaal]

Hi,

What you propose can work yes, in an ideal situation. There are quite  
some drawbacks that we suffer from however:

- Blenders event system is primitive and suffers from old IrisGL and  
Iris window manager conventions - on top of that a port to Glut  
happened, and added to that port to Ghost confused it even more. It was  
not at all designed for python hooks, usues sub-looping a lot and polls  
all the time.

- Blender's GUI is very flexible, and opens in any screen resolution  
and color depth, and allows users to tweak UI conventions as well.  
Further it depends on OpenGL redraws, which (can) give different  
results or timings on different OS's. Nailing down these variables to a  
single 100% reliable testing situation isn't easy.

- And... I realize in a more professional environment, each new feature  
in code should be accomplished with a test (for others) to verify the  
the functionality. I know we should strive for more professional  
development too, but the test-file convention as you describe won't  
likely be followed easily.

I'm not blocking improvements, but try to sketch the picture, and hope  
we can find a smooth roadmap to better code and testing. What about  
this:

- Currently, more important changes in code result already in a page in  
CMS in the 'current projects' section of blender3d.org -> InfoCenter ->  
Development. This is something we can't encourage too often for  
everyone to do.

- As part of the testing project, we already discussed having better  
regression suites. I think we can require that developers who provide  
new functionality, not only give a description of it (for release logs  
and website) but also publish the .blend file(s) they used for testing  
it themselves. This can be collected as a special download in the weeks  
before release.

- For the time being, having a very well communicated and scheduled  
releasing schedule, we can achieve already quite some improvements.  
Depending on our masses of users isn't a weak point, I think we can use  
that much better still. This could be a good target for the next few  
releases to implement and get used to.

- Next to that, we could look at blender's internal event system, and  
devise something that gives better functionality in general. For python  
hooks, for user-definable hotkeys, for macros, for undo's, for  
centralized drawing purposes, and for testing purposes. Such a redesign  
is complex, and goes very deep into the core of how Blender functions.  
Not something to expect too soon, and also not something I want to rush  
into just for the sake of... :)

-Ton-






On Friday, May 28, 2004, at 23:45 Europe/Amsterdam, ChrisKeith@aol.com  
wrote:

> Tom -
>
> Thanks for the info.  Can you  point me to the files that you have  
> changed
> once you check them in?
>
> I  have a proposal for a test harness, for anyone who wants to throw  
> darts at
>  it:
>
> http://home.pacbell.net/c_keith/projects/blender/guitest/proposal.html
>
> Chris  Keith
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org