This is a quick follow up post to the previous post regarding writing tests for Google App Engine applications.
In the previous post, we just saw how to write quick functional tests to make sure the RESTful API is sane. This follow up is to shed a bit more light on py.test, and how it can be used to the fullest, as well as some more details on how the Google AppEngine (GAE) development instance is setup.
To run your functional test, you probably want to create a new instance of your server just for the sake of running your tests. This will allow you to quickly deploy a pre-release version and test it without affecting your production setup.
Luckily, GAE developers know how important command line tools (cli) are to us, and have created a cli for GAE.
Here is the basic script:
Notice that the code is in
setup_module, which is the way pytest allows you to setup your testing environment for the current test module.
The code is a simply
subprocess code that calls the GAE cli, namely
dev_appserver.py. The flags are verbose and self-explanatory.
I had some issues when using the same port over and over, since sometimes the port is not released fast enough, so I generate a random port everytime.
Make sure when executing the command, make sure the
cwd (current work directory) is the project directory, so it actually runs your app.
Finally, we poll the process till we get the “Starting admin server”, which indicates that the instance has been created and ready for use.
setup_module, we have
teardown_module. Here, we teardown the GAE instance, and cleanup all the resources.
Sometimes your tests might fail, but you want a chance to navigate to the instance admin page and inspect the datastore, memcache, or whatnot. So, if you see the code below, it actually never exits, since it is constantly polling the process.
Finally, I would like to mention the flags that are super useful for these pytests. They are just two, honestly.
-v is verbose, as with any other command. I am a glutton for nice output with lots of green text, and that flag gives me that.
-s pipes the output of all the print statements we have in the tests out to the terminal, so I use this one if a test fails, and I want to know more about what’s happening on the instance output side.
It’s very simple to setup tests for GAE, and even more so create and teardown instances on the fly to perform tests. There aren’t many reasons I can think of not to test your code, but a lot of reasons to do otherwise. So… write tests, and use the extra time to play League!