Programming: A concise tutorial on django-nose-selenium.

So you’d really like to perform integration testing on your Django site, to exercise the whole stack right from the client-side Javascript through to the database at the backend. There are a million ways to do this, but only a few work. Of the few that work, none have a fully worked out example showing you how to get them up and running. Enter this blog post! In this, I’m going to show you as compactly as possible how to get django-nose-selenium working on your Django 1.3 test setup.

First install the necessary packages. I use virtualenv (you should do), so that means:
[shell]
pip install django-nose
pip install git+https://github.com/weluse/django-nose-selenium.git
# we’re going to use the cherrypyliveserver
pip install CherryPy
[/shell]
Better yet, add these to your pip requirements file.

In your settings.py file, make the following modifications and additions:
[python]
# so that "python manage.py test" invokes django-nose-selenium
TEST_RUNNER = ‘django_nose.NoseTestSuiteRunner’
# should match SELENIUM_URL_ROOT which defaults to http://127.0.0.1:8000
LIVE_SERVER_PORT = 8000
.
.
DATABASES = {
‘default’: {
# TEST_NAME is absolutely CRITICAL for getting django-nose-selenium
# going with sqlite3. The default in-memory breaks everything.
‘TEST_NAME’: os.path.join(project_path, ‘test_sqlite.db’),
.
.
}
}
.
.
INSTALLED_APPS = (
.
.
# this HAS to go after ‘south’ if you have that in your INSTALLED_APPS
‘django_nose’
)
[/python]

Most importantly here, if you’re using sqlite3, is to specify TEST_NAME. If you don’t do this, Django by default uses an in memory sqlite3 database, and this breaks in infuriatingly mysterious ways, for example yielding “DatabaseError: no such table: django_site” or the same for “django_session”, while you can see that the test framework is creating those tables. After hours of frustration, I stumbled upon this important tidbit in this django-nose-selenium issue report.

Now you can start writing tests! Below is an example, which lives in project/app/tests.py, that loads up the front page, and also tries to log in. You can use the selenium IDE (firefox extension) to generate the Python exercise code you see below. I’m also making use of selenium_fixtures to load in two users into the database (the fixture itself is shown below this example):

[python]
from django.utils import unittest
from noseselenium.cases import SeleniumTestCaseMixin
from the_project.the_app.models import User

class TestSelenium(unittest.TestCase, SeleniumTestCaseMixin):
# this fixture adds two users: admin/admin and test/test
# this data stays in the specially created test DB for the whole run!
selenium_fixtures = [‘test_data1.json’]

def test_ok(self):
""" check that the front page has correctly loaded
and that there’s a login link.
"""
sel = self.selenium
sel.open("/")
self.failUnless(sel.is_text_present("Login to System"))

def test_login(self):
"""Test that the user can actually login."""

sel = self.selenium
sel.open("/")

sel.click("link=Login")
sel.wait_for_page_to_load("30000")
sel.type("id=username", "test")
sel.type("id=password", "test")
sel.click("css=input[type=\"submit\"]")
sel.wait_for_page_to_load("30000")

self.failUnless(sel.is_text_present("Logout (test)"))

[/python]

I generated the fixture with the django dumpdata command. It exists as project/app/fixtures/test_data1.json and it looks as follows (one of the two users removed for brevity):
[js]
[
{
"pk": 1,
"model": "auth.user",
"fields": {
"username": "admin",
"first_name": "",
"last_name": "",
"is_active": true,
"is_superuser": true,
"is_staff": true,
"last_login": "2011-08-27 01:02:53",
"groups": [],
"user_permissions": [],
"password": "sha1$0faea$31f62ca99c405cad9cbe0bd469baeb8b3b6b923c",
"email": "admin@admin.com",
"date_joined": "2011-08-27 01:02:37"
}
},
[/js]

Once all of this has been setup, first startup the Selenium RC server as explained here. In short, download from here, and invoke like this:
[shell]
java -jar selenium-server-standalone-2.5.0.jar
[/shell]

Then, finally, invoke the tests as follows:
[shell]
python manage.py test –with-selenium –with-cherrypyliveserver –with-selenium-fixtures
[/shell]

–with-selenium specifies that selenium tests should be executed, –with-selenium-fixtures that selenium fixtures should be loaded and cherrypyliveserver that the CherryPy multi-threaded webserver should be used instead of the built-in django one that’s not really multi-threading ready.

Let me know in the comments if this helped, or if I need to add or fix anything.

P.S. I also wasted a few precious hours with django-sane-testing. Fixtures didn’t work, python manage.py test didn’t work in spite of having correct TEST_RUNNER configured, and it also didn’t serve static files. It also complained about django_session not existing, so it could be that specifying TEST_NAME there might help for that bit.

Beating the Meeting Monster

Ideally, we would have a system or a tool that would unify the scheduling of meeting and of tasks, that is, the actual work that needs to be done. As it is, however, task management systems and the calendaring software that is used to schedule meetings are two separate entities and usually don’t support the most minimal coordination. This often means that you just keep on planning meetings as long as your calendar still allows it, at the same time burning the time that you need to get around to your tasks. In other words: Meetings, although they can be useful, are productivity killers.

The Arctic Council observers meeting 02

Until our systems are able to unify task and meeting scheduling, here’s a simple but golden tip to minimise the detrimental effect of meetings on your productivity. Make the deal with yourself, and as many as possible of your colleagues, that you only schedule meetings in the afternoons. This is hard at first, especially because you sometimes do have to (graciously) decline making meeting appointments, even if the only possibility is in the morning. Think about it this way: If you don’t do this, you’re going to have to spend nights and weekends catching up on the actual work, so you are absolutely in your right saying no. This approach has the added advantage of keeping your mornings free for contiguous blocks of concentrated work, when most people are at their intellectual best.

Let us know in the comments what you think!

Why am I not in a pomodoro?

When you combine Getting Things Done (GTD) with the Pomodoro Technique (PT), the result is super hero productivity. PT entails that you work in 25 minute blocks of ultimate focus, referred to as pomodoros, each followed by 5 minutes of ultimate goofing off. After every 4 pomodoros, you get to take a longer break. Pomodoro people tend to use some form of kitchen timer (often in the form of a red tomato), or software such as the Focus Booster, and they tend to be at least three times as productive. 🙂

How can a technique named after something this red and tasty not be fantastic?

Whatever the case may be, we’re great fans of the technique and as a rule combine it with our GTD implementation. We do sometimes refer to the pomodoros as “work units”, as this is sometimes easier to explain to management. One might think that 25 minutes is quite short, but most people are generally quite amazed by the high level of focus that can be maintained during this period. The 5 minute break is almost like spending time under the shower: Deliberately goofing off and not thinking about the problem at hand often allows solutions and really good ideas to bubble up spontaneously from one’s sub-conscious.

Besides convincing you of the benefits of PT, the main message of this post to those of you already applying PT, is the following: At any time during the (work) day, if you’re not in a pomodoro or in the short break between pomodoros, you should ask yourself this question: Why am I not in a pomodoro?

In other words, one should either have a really good reason for this, or immediately start that new pomodoro. We noticed in ourselves,before we became TimeScapers of course :), and in other practitioners that people sometimes operate OOP (out-of-pomodoro) because they think that the activity doesn’t fit, for example mail processing or some other miscellaneous small action. Our advice is ABP: Always Be Pomodoroing. The risk with working OOP is that it can spiral out of control, breaking the whole PT focus-zone/goofing-off rhythm, and this is a productivity killer. Don’t fool yourself: You can and should always define a pomodoro.

Let us know in the comments what your experience is with this phenomenon, or if you’d just like to chat about PT in general.

The micro morning planning session

GTD considers the daily review to be an important component of effective time management. Here at TimeScapers, we agree strongly with this sentiment, although we prefer to implement this as the micro morning planning session. This is the very first thing that you should do when starting at work, and if done well, helps to ensure a productive and especially effective day.

Planning close-up

You will notice that if you arrive at work and immediately open your email, your day can easily turn into a purely reactive one, where you find yourself spending the most of your time simply trying to work away all the emails in your inbox. If you think about it, this means that you allow other people, the mostly well-intentioned senders of the emails that face you, to determine your daily activities, instead of yourself.

Instead of this, we recommend that you take 10 minutes to plan the activities you will undertake. In the first few minutes, take some time to think about the projects that are really important, and not necessarily urgent, to you. These are the projects that really create value, for example things that will help you advance your career. Write down three to four of these tasks in your daily journal document (you have one of those right?) that will help you to advance the important projects.

Next, open up your todo list and add the tasks to your list that are urgent, i.e. those things that really need attention today, for example due to imminent deadlines. These tasks should of course be completed on time, but do note that there is often a difference between important and urgent. The former generally creates more value, the latter is mostly damage control.

Finally, and you might even postpone this until after a few hours, open your email and check for any really urgent matters. These can be added to your list of tasks for the day. We recommend that you postpone your real email processing (that is where you turn emails into tasks that can be inserted into your todo system) until about mid-day. The morning check is purely for emergencies.

Following this procedure, you will start your day working on a well-balanced list of tasks that will ensure that you not only take care of urgent matters, but that you also work an advancing the far more important big picture. This is an important step in applying your long-term vision to your work day.

Let us know what you think in the comments!