Test-Driven Development with Python

Appendix A. PythonAnywhere

This book is based on the assumption that you’re running Python and coding on your own computer. Of course, that’s not the only way to code Python these days, you could use an online platform like PythonAnywhere (which is where I work, incidentally).

It is possible to follow along with the book on PythonAnywhere, but it does require several tweaks and changes — you’ll need to use a virtualenv from the very beginning, you’ll need to set up a web app instead of the test server, you’l need to use Xvfb to run the Functional Tests, and, once you get to the deployment chapters, you’ll need to upgrade to a paying account. So, it is possible, but it might be easier to follow along on your own PC.

With that caveat, if you’re still keen to give it a try, here are some details on what you need to do.

If you haven’t already, you’ll need to sign up for a PythonAnywhere account. A free one should be fine.

Then, start a Bash Console from the consoles page. That’s where we’ll do most of our work.

Starting a virtualenv

At the time of writing, PythonAnywhere had Django 1.6 as its default version under Python 3. Since we need a newer version than that, we’re going to use a virtualenv (in the book, we start using a virtualenv a bit later, in Chapter 8).

Here’s how to create a virtualenv named “superlists” and install Django and Selenium into it:

$ mkvirtualenv --python=/usr/bin/python3.4 superlists
Running virtualenv with interpreter /usr/bin/python3.4
Using base prefix /usr
New python executable in superlists/bin/python3.4
Also creating executable in superlists/bin/python
Installing setuptools, pip, wheel...done.
(superlists)$ pip install django==1.8.4 selenium
Collecting django==1.8.4
[...]
Successfully installed django-1.8.4 selenium-2.46.0

Notice how the prompt changed to have (superlists) at the beginning of it; that tells you your virtualenv is active. You can check it’s active by seeing what the versions of Python and Django are:

(superlists)$ python --version
Python 3.4.0
(superlists)$ python3 --version
Python 3.4.0
(superlists)$ python3 -c"import django; print(django.get_version())"
1.8.4
(superlists)$ deactivate
$ python --version
Python 2.7.6
$ python3 --version
Python 3.3.6
$ python3 -c"import django; print(django.get_version())"
1.6.6

From now on, always look out for that (superlists)$ prompt. If it’s not there, you need to activate your virtualenv, using the workon command:

$ *python3 -c"import django; print(django.get_version())"*
1.6.6
$ *workon superlists*
(superlists)$ *python3 -c"import django; print(django.get_version())"*
1.8.4

Running Firefox Selenium Sessions with Xvfb

The next thing is that PythonAnywhere is a console-only environment, so it doesn’t have a display in which to pop up Firefox. But we can use a virtual display.

In Chapter 1, when we write our first ever test, you’ll find things don’t work as expected. The first test looks like this, and you can type it in using the PythonAnywhere editor just fine:

from selenium import webdriver
browser = webdriver.Firefox()
browser.get('http://localhost:8000')
assert 'Django' in browser.title

But when you try and run it (in a Bash console), you’ll get an error:

(superlists)$ python3 functional_tests.py
Traceback (most recent call last):
File "tests.py", line 3, in <module>
browser = webdriver.Firefox()
[...]
selenium.common.exceptions.WebDriverException: Message: 'The browser appears to
have exited before we could connect. The output was: Error: no display
specified\n'

The fix is to use Xvfb, which stands for X Virtual Framebuffer. It will start up a “virtual” display, which Firefox can use even though the server doesn’t have a real one.

The command xvfb-run will run the next command in Xvfb. Using that will give us our expected failure:

(superlists)$ xvfb-run python3 functional_tests.py
Traceback (most recent call last):
File "tests.py", line 11, in <module>
assert 'Django' in browser.title
AssertionError

So the lesson is to use xvfb-run whenever you need to run the functional tests.

Setting Up Django as a PythonAnywhere Web App

Shortly after that, we set up Django, using the django-admin.py startproject command. But, instead of using manage.py runserver to run the local development server, we’ll set up our site as a real PythonAnywhere web app.

Go to the Web tab and hit the button to add a new web app. Choose “Manual configuration” and then “Python 3.4”.

On the next screen, enter your virtualenv name (“superlists”), and when you submit it should autocomplete to /home/yourusername/.virtualenvs/superlists.

Finally, click through to the link to edit your wsgi file and find and uncomment the section for Django. Hit Save and then Reload to refresh your web app.

From now on, instead of running the test server from a console on localhost:8000, you can use the real URL of your PythonAnywhere web app:

    browser.get('http://my-username.pythonanywhere.com')

Note

You’ll need to remember to hit Reload whenever you make changes to the code, to update the site.

That should work better.^[39] You’ll need to keep using this pattern of pointing the FTs at the PythonAnywhere version of the site, and hitting Reload before each FT run, until Chapter 6, when we switch to using LiveServerTestCase and self.live_server_url.

Cleaning Up /tmp

Selenium and Xvfb tend to leave a lot of junk lying around in /tmp, especially when they’re not shut down tidily (that’s why I included a try/finally earlier).

In fact they leave so much stuff lying around that they might max out your storage quota. So do a tidy-up in /tmp every so often:

$ rm -rf /tmp/*

Screenshots

In Chapter 5, I suggest using a time.sleep to pause the FT as it runs, so that we can see what the Selenium browser is showing on screen. We can’t do that on PythonAnywhere, because the browser runs in a virtual display. Instead, you can inspect the live site, or you could “take my word for it” regarding what you should see.

The best way of doing visual inspections of tests that run in a virtual display is to use screenshots. Take a look at Chapter 20 if you’re curious—there’s some example code in there.

The Deployment Chapter

When you hit Chapter 8, you’ll have the choice of continuing to use PythonAnywhere, or of learning how to build a “real” server. I recommend the latter, because you’ll get the most out of it.

If you really want to stick with PythonAnywhere, which is cheating really, you could sign up for a second PythonAnywhere account and use that as your staging site. Or you could add a second domain to your existing account. But most of the instructions in the chapter will be irrelevant (there’s no need for nginx or gunicorn or domain sockets on PythonAnywhere).

One way or another, at this point, you’ll probably need a paying account:

• If you want to run your staging site on a non-PythonAnywhere domain
• If you want to be able to run the FTs against a non-PythonAnywhere domain (because it won’t be on our whitelist)
• Once you get to Chapter 9, if you want to run fabric against a PythonAnywhere account (because you need SSH).

If you want to just “cheat”, you could try running the FTs in “staging” mode against your existing web app, and just skip the fabric stuff, although that’s a big cop-out if you ask me. Hey, you can always upgrade your account and then cancel again straight away, and claim a refund under the 30-day guarantee. ;)

Note

If you are using PythonAnywhere to follow through with the book, I’d love to hear how you get on! Do send me an email at [e-mail].

---

^[39] You could run the Django dev server from a console instead, but the problem is that PythonAnywhere consoles don’t always run on the same server, so there’s no guarantee that the console you’re running your tests in is the same as the one you’re running the server in. Plus, when it’s running in the console, there’s no easy way of visually inspecting how the site looks.