Browser tests aren't the only (and often not the best) way to test browser views. Much nicer to just instantiate the view directly, like so:

>>> view = FooView(context, request)

Then just call any method of the view directly:

>>> self.assertEqual(view.foo(), [])

But where to get the request? Enter TestRequest:

>>> from zope.publisher.browser import TestRequest
>>> request = TestRequest()
>>> view = FooView(context, request)
>>> self.assertEqual(view.foo(), [])

However, sometimes this can result in the following error:

TypeError: ('Could not adapt', <zope.publisher.browser.TestRequest instance URL=http://127.0.0.1>, 
    <InterfaceClass zope.annotation.interfaces.IAnnotations>)

In that case you additionally need to make the request object you've just created annotatable, like so:

>>> from zope.publisher.browser import TestRequest
>>> from zope.annotation.interfaces import IAttributeAnnotatable
>>> from zope.interface import alsoProvides
>>> request = TestRequest()
>>> alsoProvides(request, IAttributeAnnotatable)

One of the nice features of subversion are its built-in command aliases, i.e. instead of having to type svn commit you can just use svn ci, instead of propertyedit just type pe.

git doesn't have those, which some find annoying. However, you can easily remedy this by adding an [alias] section to your ~/.gitconfig file. Upon request and because it's really a nice feature here's an example for that from my own configuration. I've copied it myself mostly from Andi, who is as much more prolific than I as he is lazier to blog ;-)

Anyway, here it goes:

[core]
    excludesfile = /Users/tomster/.gitignore
    pager = "/opt/local/bin/less -RciqMSj5"
    editor = mate -w

[color]
    diff = auto
    branch = auto
    status = auto

[diff]
    renames = true

[alias]
    st = status
    d = diff
    ci = commit -v
    cia = commit -v -a
    co = checkout
    cp = cherry-pick
    l = log
    ll = log -p
    lt = log trunk..
    llt = log -p trunk..
    lm = log master..
    llm = log -p master..
    b = branch

The .gitignore file referenced above looks like this (and should look rather familiar to svn users):

.svn
*.egg-info
*.pyc
.DS_Store
tmtags

Update: @philikon found the FM :-)

The sprint started with a brainstorming session where we collected all the ideas and areas the participants brought into three core areas. They have been tentatively named Cataloging and Indexing, Instrumentation and Benchmarking. We then proceeded to collect input on these three areas by having everybody write down whatever came to mind on post-its and we just stuck them together on the wall.

After lunch we split up into three groups where all the input for each topic was processed. The group session was limited to just over an hour, as the goal was not to jump into (anf get lost in) an exhaustive discussion of all aspects and details but rather to come up with specific, actionable proposals which would then be put to the entire sprint in a short presentation, where we collectively decided on what (partially already how) we were going to work on for the remainder of the sprint.

This approach turned out to be a really good idea for multiple reasons. For one, we collectively decided on what we would concentrate on. Nobody had to feel left out. By limiting the first session to an hour and demanding a short presentation from each group to the entire sprint, we avoid rushing into dead ends. And lastly, everybody was on the same picture from the very start.

The three presentations then provided each group with further feedback and by the time they were over everybody was ready to get some actual work done.

We ended day one by rewarding ourselves with a big dinner of real authentic English food (i.e. Indian curry) in an old converted bank.

While cleaning up on the remoteinclude sprinting we did last week at the post-conference sprint, I came across Windmill. Windmill looks like a really promising candidate for anyone wishing to do some non-trivial browser based testing of their web applications:

Windmill implements cross browser testing, in-browser recording and playback, and functionality for fast accurate debugging and test environment integration.

I'd be curious to know if any members of the Plone/Zope community have had any experiences with it. Also, if you've simply become curious and would like to try it out for yourself (and then report back) but are intimidated (or simply put off) by the lengthy installation instruction, here's a one-stop buildout including the particular python that windmill needs, that will get you going:

[buildout]
python = python
parts =
    python
    pythonbin
    windmill

[windmill]
recipe=zc.recipe.egg
eggs =
    simplejson==1.9.1
    windmill

[python]
recipe = zc.recipe.cmmi
url = http://www.python.org/ftp/python/2.5.2/Python-2.5.2.tgz
executable = ${buildout:directory}/parts/python/bin/python2.5
extra_options=
    --enable-unicode=ucs4
    --with-threads
    --with-readline
    MACOSX_DEPLOYMENT_TARGET=10.5 # uncomment this, if your're not on MAC OS X

[pythonbin]
recipe = plone.recipe.command
command = ln -s ${python:executable} ${buildout:bin-directory}/python

Update: Martijn Peters points out, that you can use newer versions of simplejson, you just need to stick to the 1.9 branch for the time being:

"because I assume it's the 2.0.0 API change that makes them use 1.9.x on their instruction pages. It works just fine with 1.9.3 anyway, haven't tried 2.0.3 at all."

I've updated the buildout above accordingly. Also, if you already have a working python2.5 on your system (unlike yours truly who hosed his Mac OS X 10.5 python2.5 ages ago) you can reduce the buildout to this snippet:

[buildout]
parts =
   windmill

[windmill]
recipe=zc.recipe.egg
eggs =
   simplejson <=2.0.0dev
   windmill