Re: [pygame] TODO: add pygame unittests, and test runner stuff to pygame.test package.

["René Dudfield" <renesd@xxxxxxxxx>]

hey,

yeah, these are exactly the things we'd like to do.  Nicholas has been
extending Brians 'spectaularly adequate pygame build page' so that it
is more suitable for storing, and reporting test run information.


cu!



On Sun, Sep 14, 2008 at 5:53 AM, Ron Dippold <sizer@xxxxxxxxxx> wrote:
> I like it. I'm a big fan of TDD, especially with something that has as many
> dependencies as pygame (which OS, which SDL, which drivers, which version of
> python, etc).  It looks like you're thinking along these lines too, but just
> to spell it out, it should probably spit out out a summary in a compact form
> with all version info you can find and and test abnormalities so when people
> say 'something doesn't work!' you can tell them to run the tests and copy
> and paste the summary. Performance choices (alpha? HWSURFACE?) could be
> another slightly less important but useful summary section.
>
> If the summary was easily computer parsable it would also make it easier to
> publish a compatibility matrix - for instance pygame.music 1.8.1 on Windows
> will happily load/play mp3s, mods, midis. Does this work under linux? I have
> no idea (I have a linux box with pygame, but it's display/audioless) but it
> would be nice to consider when writing a game. It would be very easy to have
> the results http POSTed somewhere (with user consent) and summarized. Not to
> make even more work for you guys, but it would be something to consider.
>
> Not sure how much it would add to the download size, but we're only at 1.4MB
> right now, be worth an extra couple hundred kbytes.
>
> Ron
>
> René Dudfield wrote:
>>
>> hi,
>>
>> what do you think of a pygame.test package?
>>
>>
>> Here's an idea Nicholas and I have been discussing for adding the
>> pygame unittests, and test framework into a pygame module.
>>
>> We haven't really threshed out the ideas fully yet, but here are the
>> notes for further discussion.
>>
>>
>>
>>>>> # load the various tests.
>>>>> pygame.test.load()
>>
>>>>> # run the tests.
>>>>> pygame.test.run()
>>
>>>>> # module for generating stubs for untested code.
>>>>> pygame.test.gen_stubs
>>
>> That is, making the tests a package of pygame.
>>
>>
>> Why?
>> =====
>> - people can run the tests to see if everything works in their own
>> programs.
>>    - So you could for example run the tests on a persons computer to
>> see if everything in pygame+ your program is working.
>>    - you could also test which driver/function combination works, or
>> works fastest.
>> - it would make testing a py2exe/pyapp generated binary much easier.
>> - other people can use our testing framework enhancements for their own
>> tests.
>> - would make bug reporting easier.  Since everyone could run
>> unittests, since they will be installed everywhere pygame is
>> installed.
>> - would allow unittest result submission easy.  This would result in a
>> much larger base of computers running the unittests and submitting
>> problems.  This would be opt in of course.
>> - make the testing stuff more a library, than a framework.
>> - allow people submit unittests more easily.  Since they won't require
>> a source release of pygame to write unittests.  eg people using a
>> windows binary install of pygame, or a ubuntu binary install can run
>> and submit unittests.
>>
>>
>>
>> How will it affect writing tests?
>> ======================
>>
>> Hopefully it won't.  Tests will be written as they are now.
>>
>> Probably have to make the tests not rely on data in examples/data
>> directory like some do.
>>
>> Will allow more people to write unittests.  Since they won't need the
>> source install of pygame.
>>
>>
>>
>> How do you plan to implement it?
>> ========================
>>
>> Not sure yet.
>>
>> keep the test directory as it is now... basically on install... make a
>> copy of it?
>>
>> Will need to move some stuff around.  Probably move some stuff into a
>> lib/test/ directory.
>>
>
>