Re: [pygame] unit and doc testing questions

["Patrick Mullen" <saluk64007@xxxxxxxxx>]

On Wed, Jan 14, 2009 at 12:58 PM, Jake b <ninmonkeys@xxxxxxxxx> wrote:

>> are pretty much inherently checking for compiler errors, so there is no
>> need to test for the compiler
>> explicitly.
>
> Don't know what you mean? I'm not testing for compile errors?

You mentioned having compile time tests, there is no reason to, but
stuffing some tests into a module to have it run whenever the module
is imported can be a quick way to go about it if you don't need the
flexibility of test runners.  It sounds like for what you are doing
you might need as much flexibility as you can get.

> I can convert most of the render test like you said. But I'm more curious
> when a case comes up that it just takes too long. ( Not specifically
> rendering , but just a unittest in general that requires time.)

What is the test you are talking about that is too slow?  My tests are
collectively slow, but I don't have any major problem cases that sound
like what you describe.

I guess sometimes though you can't get away from it.  Structure it
however necessary that the other tests tell you everything else, and
set things up to still let you run everything when you need to (always
running everything when you are think you are "finished" with
something.)

Another option for slow tests, is if the part that is slow can be
reused in more than one test, you can save time by caching that
operation.  This is the purpose of test fixtures - build/set up some
stuff, then run these tests using it.  But fixtures can cause issues
if you aren't careful, because running the tests in different orders
or at different times may have different results, depending on what's
going on inside the fixture between runs.

Don't forget to do integration testing in addition to unit testing!  I
have an experiments file where I just play with the system and
classes. I have found bugs there that my unit tests missed. Sometimes,
I was able to take the experiment and turn it into another unit test,
other times it wasn't worth it to do so.  This was my first serious
attempt at testing, so I was a bit surprised when I had many unit
tests and thought things were peachy, but found many problems when I
started experimenting.