[pygame] pygame unittests

["Nicholas Dudfield" <ndudfield@xxxxxxxxx>]

Greetings all,

akalias here, your GSOC student with the Pygame Testing project.

One of the stated goals of my gsoc project is to have a really broad
coverage of tests. And in fact my first coding period was planned to be
spent on that. It's a fairly big task.

To that end I have been working on a unittest stub generator that uses
introspection to create stubs of tests automatically.

Eventually I want the stubber to be able to be used something like this:
    
    gen_stubs.py --needed pygame.color >> color_test.py

That would append stubs for all units (callables) from pygame.color that are
not currently tested. To keep it simple, I would just append the stubs and
people can spend the two seconds manually placing them.

How would you know what functions aren't tested? An idea I am toying with is
to create a consitent naming scheme that we can all agree upon for the tests
(renaming existing tests) that makes it easy to determine which unit's are
already tested.

The idea would be to inspect a module and based upon the names of it's tests
determine which units(functions) are tested.

For example let's look at the method pygame.font.Font.get_ascent:

    What information is needed?

    pygame.       N: All unittests are for pygame
    font.         N: The tests are categorized into files, eg font_test.py 
    Font.         Y: is a class and unique namespace 
    get_ascent    Y:     what if there was pygame.font.get_ascent ? 

eg.

    class + description optionals separated by double underscore

        Class__method__description
        
        pygame.font.Font.get_ascent -> becomes
            
            def test_Font__get_ascent(self)
        
        pygame.font.get_ascent -> becomes
            
            test_get_ascent(self)
            
            test_get_ascent__attacks_when_cornered(self)
            
            ...

So for pygame.font.Font.get_ascent if there was existing tests that started
with "test_Font__get_ascent", the proposed utility would skip creating that
stub.

Issues
====== 

An issue with this naming scheme is methods prefixed or suffixed with
underscores.

If we are only aiming at public methods this is a non issue. 
    
What "private" methods to test? What is the minimum coverage to aim for ?
    
(the scope of the stub generator is all that's under discussion)


What are peoples thoughts. Is this a path worth venturing down? It would
mean renaming existing tests.