Re: [pygame] Working on Retro 80s Game SDK, Looking for general support

["Patrick Mullen" <saluk64007@xxxxxxxxx>]

On Wed, Jan 7, 2009 at 3:51 PM, Jake b <ninmonkeys@xxxxxxxxx> wrote:
> On Wed, Jan 7, 2009 at 2:00 AM, Patrick Mullen <saluk64007@xxxxxxxxx> wrote:
>>
>> On Tue, Jan 6, 2009 at 10:59 PM, Jake b <ninmonkeys@xxxxxxxxx> wrote:
>> through, I use the "assert" statement to make sure that the frame counter
>> is no
>> longer progressing.  Later, if I change some of the animation code
>> somewhere that
>> might mess up the play_3_times behavior, when i run the tests that
>> test will error,
>> and I'll know I broke something.
>
> Do you use the assert statement, or do you have a function like this?
> def _assert(exp, msg=""):
> """An assert() function.
> source: http://www.gamedev.net/community/forums/topic.asp?topic_id=496793""";
> if __debug__ and not exp:
> import pdb
> print "\n_assert failed:\n\t%s\n" % msg # or: simple: print "_assert failed:
> ", msg
> pdb.set_trace()
> --
> Jake
>

Yeah, I just use assert statements for the most part.  I don't touch
debuggers, not that they wouldn't help, I am just so used to
sprinkling print statements everywhere that I don't think of it.  The
important thing is that the tests are separate from the rest of the
code.  Most of them generally look like this:

def test_something():
   o = create_object_somehow()
   o.do_something()
   assert o.state == something

Then I have a file that imports the files with the tests and runs all
of the functions.  If a function errors, I catch the exception and
print it, but continue to the next test.  That way I can see a
pattern. If I have 10 tests that all fail with the same exception, it
becomes pretty clear what I did that screwed it up.

This isn't any different from what UnitTest or doctest (or py.test, or
nose, or ...) do.  Some of the test suites I've seen use asserts
like me, others have their own equality-checking functions.  I do have
a special function for comparing images, but that's a special case.

I would say my test code is roughly 3 times longer than my actual
code.  Currently I have about 170 tests, so it's getting to be a bit
scary, but I think it's the right way to go.  I feel a bit more secure
than I did before, but it could be a false sense of security.  We'll
see when I release it how the bug reports go, versus the last version
I released.  Coding speed seems roughly equivalent to before when I
wasn't doing tests.  Most of the time I spend writing tests now I
would have done before in writing comments or just planning things
out.

If you want to get into unit testing and test-driven development, I
recommend doing some research on it, it's not a skill that comes
naturally.  I was indoctrinated in school (and they are always going
on about it on blogs and such), but it still took me a while to
actually apply it to a personal project.

By the way, do you have your code in a repo somewhere?  I'd be
interested in checking it out.