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 set up a web app instead of the test server, you’ll 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.
The first 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_01], 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.titleBut when you try to run it (in a 'Bash console'), you’ll get an error:
(superlists)$ python 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 python 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.
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.[1] 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_working_incrementally], when we switch to using LiveServerTestCase and
self.live_server_url.
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/*
In [chapter_post_and_database], 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_CI] if you’re curious—there’s some example code in there.
When you hit [chapter_manual_deployment], 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_automate_deployment_with_fabric], 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 obeythetestinggoat@gmail.com. |