RE: [pygame] Google Summer of Code: Testing

["Nicholas Dudfield" <ndudfield@xxxxxxxxx>]

Brian,

Thanks for your reply. I have been chewing over it a bit and if I understand
you correctly you have 2 main points.

necessity of the mundane
========================

"arguments you pass to create or init something are actually respected"

I think that these are probably the most import parts to test. The meat and
potatoes. Do my plans sound too ambitious? 

don't jump too quick into interactive testing
=============================================

"best facilitated by adding functionality to pygame that reports on
internals of things"

I think that's a good point. Try where possible to use automated testing. Is
this the point you were making? Yes, the interactive tests will be more an
enhancement rather than a replacement. I see interactive tests as useful for
"testing the tests". Is this function that reports on the internals working
correctly? Everything _seems_ fine, the tests are passing but it's not
working. It's about automating and structuring as much as possible all the
little checks you would do anyway but in an ad-hoc manner.

Let me know if I am not understanding you correctly. I want to be on the
same page.

Nick.


From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx] On
Behalf Of Brian Fisher
Sent: Friday, May 02, 2008 3:20 PM
To: pygame-users@xxxxxxxx
Subject: Re: [pygame] Google Summer of Code: Testing

Hey Nicholas,
 That all sounds great. I have a suggestion about modules that would warrant
an "interactive" test like audio - pygame has had bugs (and probably still
does) that relate to the mundane bits of using an interface - like that the
arguments you pass to create or init something are actually respected. Or
that a particular function even supports keywords where the docs seem to
indicate it would. My point being that even if you don't thoroughly test the
functionality of something like sound, you still may find lots of good stuff
in testing boring bits like those, so I'd suggest you don't overlook them.
Also, some testing may be best facilitated by adding functionality to pygame
that reports on internals of things, maybe from existing SDL functions -
like in the case of the mixer being able to get the values that the mixer
was actually init with - or in the case of the screen being able to find
what video backend was used.