[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] unit and doc testing questions



hi,

it can be good to mark your slow tests somehow, so you can run them separately.

With pygame we extend the python unittest module to allow specifying
tags(categories) for tests.  This allows us to also use interactive
tests, and other tests you may not want to run every time.

However you could just move them into a different directory, and
change your test runner to look in a different directory given a cmd
line option... you don't need any fancy testing framework.

doctests can be a quick way to do testing.  You can create your code
in the interactive interpreter, then paste the output into the doc
strings.  You can use doc tests, and unittests together too... so the
doc tests can be run in a unittest test runner.


cheers,


On Thu, Jan 15, 2009 at 5: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.
>
>>
>> "Compiling" is a very nebulous, automatic and invisible step in Python.
>> I run the tests whenever I want to get some feedback on my code, and
>> also before committing my changes to the source control system (you have
>> one, right?)
>
>
> So for yours, you manually hit a button / click shortcut / whatever to run
> tests? None are automatic? ( Or maybe you do on central code check-in
> computer. Where it runs fast ones right then, and the slow tests on an
> interval. )
>
> I say 'compiling', because I found a method in the python cookbook that says
> "you want to ensure your modules tests are run each time your module is
> compiled."
>
> It pretty much does "if module is imported, but not main script, and needs
> recompile(because was changed): then run tests"
> --
> Jake
>