Re: [pygame] unit and doc testing questions

["Patrick Mullen" <saluk64007@xxxxxxxxx>]

On Wed, Jan 14, 2009 at 10:57 AM, Jake b <ninmonkeys@xxxxxxxxx> wrote:
>
>> > 2) Do you have two seperate unittests ? (A) One is ran every time source
>> > files are compiled, and a second, (B) slower one is ran at a longer
>> > interval
>> > for slow tests ?
>>
>> Such separation is rarely necessary.
>
> Something I started on, requires rendering. It's not a huge delay, but I
> don't want it happening every time I hit f5, while the other tests are fast
> that they can every time.
>
> I'm not totally sure how I'm going to handle this. For now I'm manually
> running the slow one, but.

In my system, all of my tests are categorized, and I have a flag in
the run tests script
that determines which categorys I want.  While debugging, I only run "new"
tests (any tests I am working on or recently added, I tag as new).  Before
I check into version control, I make sure to run all of the tests
first, but setting
the flag in the run tests script to all categories.  Running all of the tests
does take a while (more than a minute), but the slow tests don't delay
my debugging/coding.

Another option, which might have merit, is to completely separate rendering
tests and other unit tests.  You can have one runner that runs the rendering
tests, and another runner for everything else.  I think rendering is a bit
fuzzy as a unit test.  You should prefer tests that don't have to
render to those
that do, and structure code in such a way that you can test as many things
without rendering as possible.  For instance, animation code doesn't need to
render to check and make sure self.frame is incrementing properly.

But, there are certainly cases where rendering needs to be tested.  Just make
sure to only test it when necessary.  Example (semi-real): I have
20ish tests for positioning an
object.  If I were to draw the object in each test, it would be very
slow.  Instead,
the 20 tests check the result of a get_screen_pos() rather than render
the object
outright.  Most of the logic that used to be in the object.draw()
method is refactored
to the get_screen_pos method.  That way I can get by with just a few tests of
object.draw() itself, and know that since it uses get_screen_pos
(which is fully covered
by the other tests), that draw() is well covered as well.

Any of your tests or test files that import the module are pretty much
inherently
checking for compiler errors, so there is no need to test for the compiler
explicitly.  That cookbook example sounds like it is less about
compiling, and more
of a way to implicitly run tests when the application runs.