CODEWITHSUNDEEP
pythonunit-testingtdd
dukereg
dukereg

Reputation: 722

How do I test whether a module is imported in Python for Test-Driven Development of a game?

I am about to make a game using python and libtcod roguelike game library.

More to the point, I am using PyMock because I am just starting to learn Test-Driven Development, and I am determined not to cheat. I really want to get into the habit of doing it properly, and according to TDD I need a failing unit test before I write my first line of code.

I figure my first test of my "production" code should be that its dependency, libcotdpy, is imported.

My testing file:

#!/usr/bin/python
import pymock   # for mocking and unit testing
import game     # my (empty) production code file, game.py

class InitializeTest(pymock.PyMockTestCase):
    def test_libtcod_is_imported(self):
        # How do I test that my production file imports the libtcodpy module?

if __name__=="__main__":
    import unittest
    unittest.main()

Please:

1) (python people) How do I test that the module is loaded?

2) (TDD people) Should I be unit testing something this basic? If not, what is the first thing I should be testing?

Upvotes: 3

Views: 279

Answers (3)

Gishu
Gishu

Reputation: 136613

Even if there is a way to test that, I'd recommend not doing it.

Test from the client perspective (outside-in), what behavior is provided by your SUT (Game). Your tests (or your users) don't need to know (/care) that you expose this behavior using a library. As long as the behavior isn't broken, your tests should pass.

Also like another answer says, maybe you don't need the dependency - there may be a simpler solution (e.g. a hashtable might do where you instinctively jumped on a relational database). Listen to the tests... let the tests pull in behavior.

This also leaves you free to change the dependency in the future without having to fix a bunch of tests.

Upvotes: 1

Guillaume
Guillaume

Reputation: 22822

The way I usually think about TDD (and BDD) is at two levels of development: acceptance-testing level, and unit-testing level.

First thing I would do is write stories (acceptance criteria). What is the core feature of your application? Define an end-to-end scenario that explicit one feature, and goes end-to-end with it. That's your first story. Write a test for it, using an acceptance testing (or integration testing) framework. Unfortunately, I don't know Python tools, but in Java I would use JBehave, or FITnesse. It would be something very high-level, far away from the code, that considers your application as a "black box". Something like "When my input parameters are xxx, I run my application, the expected output is yyyy".

Run this test, it will fail because the underlying application doesn't exist. Create the minimal amount of classes to make it go red (and not throw an exception anymore). That's when you need to start the second phase of TDD: unit-TDD. It's basically a "descending analysis", from top-level to details, and this phase will contain a lot of red-green-refactor cycles, bringing a lot of different units in the game.

From time to time, re-run your original acceptance test, or refine it if your growing architecture and analysis forced you to make changes to specifications (theoretically, it shouldn't happen at that stage, but in practice it does, very often). When your acceptance test is completely green, you're done with that story, rinse and repeat.

All of that brings me to my point: pure TDD (I mean unit-TDD) is not practical. I mean I really like TDD, but trying to follow it religiously will be more a hassle than a help in the long run. Sometimes you will go and spike an approach to see if that goes well with the rest of your project, without writing tests first for it, and potentially rewrite it using TDD. but as long as you have acceptance tests to cover the whole lot, you're fine.

Upvotes: 4

ﾠﾠﾠ
ﾠﾠﾠ

Reputation: 66950

1) 'your_module' in sys.modules. Don't actually use that, though:

2) What should your library should do? Is it “have a dependency on libcotdpy”? I think not.

You've just made a design choice that wasn't test-driven!

Write a test that demonstrates how you want to use the library. Don't think about how you're going to implement it. For example:

player = my_lib.PlayerCharacter()
assert player.position == (0, 0)  # or whatever assert syntax `pymock` uses
press_key('k')
assert player.position == (0, 1)

Or something similar. (I don't know what you want your library to do, or how much libtcod provides.)

Upvotes: 7

Related Questions