[Pythonmac-SIG] Next PyObjC release -- help with unit tests?

[Ronald Oussoren]

On 21 Aug, 2008, at 13:31, s s wrote:

>
> On Aug 21, 2008, at 7:02 AM, Ronald Oussoren wrote:
>
>> The main problem at the moment is PyObjC: the code supports 4-way  
>> builds (or rather, 3-way builds, libffi is broken on PPC64), but  
>> the repository is not as stable as it should be.  I want to do a  
>> proper release of PyObjC, but progress is going very slowly at the  
>> moment due to lack of time and due to the general suckiness of the  
>> work that IMO must be done before a next release.
>
> Sorry if this is obvious but is there a list of these generally  
> sucky parts?

The most important things that should be done for PyObjC itself:

1) Modernize all sample projects.

A signficant subset of the examples in the repository still use  
PyObjCTools.NibClassBuilder. That module is deprecated and shouldn't  
be used in new code (and doesn't work with IB3 at all), all examples  
should be modified to work without NibClassBuilder. This means:

- Add explicit base classes instead of NibClassBuilder.AutoBaseClass
- Add outlet definitions (objc.IBOutlet definitions)
- Add @objc.IBAction decorator to actions (needed for IB3)

All examples should have a "readme.txt" and a "summary.txt", the  
latter is used on the website in the list of examples.

2) There are a number of examples in the pyobjc-core project, those  
should be moved to the most appropriate pyobjc-framework-* framework  
wrapper

3) IMHO there should be sample code for all wrapped framework, if only  
be translating an existing (Objective-)C example

4) All metadata (bridgesupport files) should be verified, see below

5) (very hard): Libffi is broken on PPC64

To be precise: the basic functionality works, but calls through libffi  
break Objective-C exception handling. This totally breaks PyObjC and  
fixing that probably requires help from a compiler guru.   My gut  
fealing is to ignore PPC64, fixing libffi is too much of an effort.

6) Port PyObjC to OSX 10.4.  This should be fairly easy once step 4 is  
finished, the code already contains the hooks that are necessary for  
this port and has worked on 10.4 in the past.

7) Move pyobjc-core/Lib/objc/test to pyobjc-core/PyObjCTest.

I've already moved the tests for framework wrappers out of the package  
that is installed by distutils, the same should be done for pyobjc- 
core. This can wait until a later release.


Py2app also needs some loving (proper egg support, testsuite), but  
that can wait until after a release of PyObjC itself.

>
>
>> I'm very, very slowly adding unittests for all global functions,  
>> and other interesting items,  in wrapped frameworks because that's  
>> the only way to be sure that the wrappers work as advertised. I'm  
>> also working on my own copy of the bridgesupport files that Apple  
>> ships with Leopard, mostly because I ran into several issues with  
>> those files and would prefer shipping my own, correct, version of  
>> the metadata files rather than trying to work around the issues in  
>> Apple's build.
>>
>> Writing these tests takes quite a lot of time and is not  
>> intellectually rewarding, which results in slow progress.
>
> Again, is there a list?  I could put in a bit of time on some of the  
> mechanical tests if I had a place to find the checklist.

There is no list, at least not outside of my head.

I've just commited the current state of the tests for the Cocoa  
frameworks, see
<https://svn.red-bean.com/pyobjc/trunk/pyobjc/pyobjc-framework-Cocoa/PyObjCTest/ 
 >.

Adding tests for other frameworks should be a lot easier, most of them  
should contain almost no entities for which tests are needed.

I'd like to see tests for all:
* C functions (CGContextCreate, ...)
* All structs: are the right fields present
* All methods that have a custom wrapper (that is, anything with a  
manually written wrapper in the Modules directory)
* All methods with pointer arguments

The tests should check if the Python wrapper works and has the right  
interface (as described in the PyObjC intro.txt document). Testing if  
the framework functions correctly is not a goal, unless a OS bug  
affects the functioning of PyObjC itself.

During this task we might run into API's that we don't want to  
support, or cannnot support, in Python. Those should be documented.

I'm currently also adding tests that check the presence of global  
variables (and values of enums), but those are less important.

Ronald