Tests related to receiving events (TDD with Panda3D and unittest)

Code Snippets
1

I’ve made some progress in getting unittest to work with Panda3D. Here’s two examples that show how you can write tests that verify that a value got changed after an event was sent.

minimal example

ScoreKeeper DirectObject example

Kindly take a look and mention the parts that seem weird or give constructive feedback if you know a better way to do things. I’m still learning Panda3D. I’m working on writing a blogpost to go along with the code examples, so point out the parts that need explaining and I’ll explain them in the blogpost later.

2

I did notice a few (fairly minor) things, if I may. Note please that I’m not familiar with the “unittest” module, so forgive me if that lack of knowledge renders any of the following irrelevant.

In the initialiser of your “ScoreKeeper” class, you don’t appear to initialise the super-class (DirectObject).

And in the “MinimalExample” program, I note that all of the tests (understandably) destroy their “testGame”–save for the first, which doesn’t. If that test is run before the others I could see it causing problems, as Panda expects there to be only one “ShowBase” object per program, I believe.

3

Both fixed. Thanks.

There’s setUp and tearDown in unittest to autoinclude things that need to happen before and after the test. Wouldnt have forgotten the testGame.destroy() if I had used that but it does make it more unreadable if you’re unfamiliar with unittest.

1 Like
4

I don’t understand at all what these systems do and why waste time writing on it. I’m generally interested in the fact that the panda build system has ever revealed anything using a similar PyTest system…

Looking at this, the impression arises that sometimes you need to write more code for testing than in the application.

5

There’s several approaches to writing software, I personally prefer Test Driven Development and I’d like to get it working with Panda3D. I’ve made good progress towards that goal.

You are still free to use any approach you prefer :slight_smile: And yes, TDD writes a lot of tests. Often it ends up about 50-50 tests vs code.

1 Like
6

I generally meant the use of such systems. This can be done using only python.

from direct.showbase.ShowBase import ShowBase

class MinimalExampleGame(ShowBase):
    def __init__(self):
        ShowBase.__init__(self)
        self.value = 'green'
        self.accept('turn-blue', self.update_value, ['blue'])
        self.accept('turn-red', self.update_value, ['red'])

    def update_value(self, newValue):
        self.value = newValue

class TestsMinimalExample():
        testGame = MinimalExampleGame()

        test = 0

        if 'green' == testGame.value:
            test += 1

        testGame.messenger.send('turn-blue')
        if 'blue' == testGame.value:
            test += 1

        testGame.messenger.send('turn-red')
        if 'red' == testGame.value:
            test += 1

        if test == 3:
            print('Ok')
        else:
            print('Failed')

        testGame.destroy()

TestsMinimalExample()

Perhaps this has a strong side, but in your example I did not see it, I am even somewhat frightened by the large amount of code.

7

Yes, we have uncovered regressions using the test suite. It is also extremely useful when we eg. rewrite the implementation of a class, to verify that all possible ways of using the class work the same way as before. In this case it saves a lot of time over manual testing.

I prefer pytest over Python’s own unittest system because a pytest unit test generally involves writing less code, and the assertions are more readable. A pytest unit test is the same amount of code as in your example, but there are useful features like the ability to easily choose which test to run on the command-line, and clear and concise command-line output about which tests pass and fail.