dropshot / dropshot-server Goto Github PK

As it stands importing dropshot.py and sslcherrypy.py generate some side-effects. When dropshot is imported it creates a database and opens sessions (that's really screwing with tests). When sslcherrypy is imported it's less frustrating, but it registers itselfas a WSGI capable server outside the SSLCherryPy class, a job I think belongs more in dropshot's court.

Add a script with ability to create an admin user before other players exist in the database.

Because of the way the set_logged_in_player hook works, right now, after we create a single player in the database we are automatically setting that player as the current_player variable to be that player. This is making it impossible to create more than one player, and thus breaking our only test...

The reason this is happening is because the request.get_cookie() is returning None, which then gets matched against the player's empty authToken in the database.

#11 illustrates the basic pattern we use for getting the optional arguments count and offset for all paginated routes. This should be DRY'ed up.

Giving users the ability to run ./dropshot.py --configure and setup basic configuration options would be a plus.

Currently the API exposes no way to delete/remove resources that have been created. While this is not desirable for a normal user it is something that an administrative user will most likely want to be able to do. Therefore it is important that we develop a way to delete any resources that the API allows users to create. It is also important that we develop this ability in a secure fashion.

Eventually, we may want to implement a lighter weight version of what Django does with their settings (see django.conf) and then implement the recommendations from Two Scoops of Django on how to create settings for different environments.

Currently, the tests "dirty" the environment. A user is created in the database, and the database isn't cleaned afterwards.

Thus, if you run the tests twice in a row without removing the database file, the tests fail the second time.

Ideally, the tests should be fully idempotent, and should continue to pass no matter how many times they're run.

Game model does not include scores and timestamp.

We now have working continuous integration! But only a very limited set of tests (and by that I mean 1). We need to expand the tests so that they cover more of the functionality of the API.

We also need to develop several types of testing. Probably a "smoke test" that tests the sequence of creating a user, authenticating, creating a game etc. logging out.

Also, integration tests that do... stuff, I'm not sure about these so much. Maybe we'll need integration tests when we have a web front-end.

Also, unit tests. ASAP

Tests need to know how to import modules that aren't in the same directory. Possible solutions to this problem may be found here. http://stackoverflow.com/a/465129 http://docs.python.org/3.3/using/cmdline.html#envvar-PYTHONPATH