Selenium, BDD and git
Paul Downey
Kerry Buckley, looking at #Selenium, #BDD and #git.
#Selenium is a great way to build and execute scripts
for testing Web applications in a browser, and looks
like a strong story for system testing TW. The IDE is
a neat Firefox extension for recording and playing
test scripts:
http://selenium-ide.openqa.org/
Especially interesting is cross browser testing
via Remote Control and Selenium Grid:
http://selenium-grid.openqa.org/
Phil Hawksworth, I and are pretty keen to apply Selenium
to RippleRap and other verticals, and if you haven't
tried it, I strongly suggest giving it a whirl!
#BDD - I guess at some point every TW developer must have
looked at one or more of the various automated unittesting
frameworks for .js and applying them to plugins. Test Driven
Development is great for driving the development of unittests
and code in unison.
I'd characterise Behaviour Driven Development
as a linguistic trick applied to Test Driven Development
to make your tests names worded in a similar style as
"User Stories". It's well worth trying,
particularly when writing code from scratch:
Although BDD works best in Ruby/RSpec where DSL makes for
a readable spec-like test suite, we found a neat
implementation for JavaScript:
http://jania.pe.kr/aw/moin.cgi/JSSpec
Phil Hawksworth, Martin Budden and I are now racing to apply
JSSpec to our plugins. Hopefully we'll have a pattern of
use for TW which others can buy into soon:
We imagine there being a MyPlugin.jsspec.js for each component
containing a series of "describe" blocks for each feature
containing a number of fine-grained "should", etc assertions.
The jsspec then gets cooked into a simple HTML file, a TiddlyWiki
and possibly run from cook using Rhino. If we can collectively put
our tests in a consistent form, we can then compile component
tests into a larger system testing framework ..
#git has momentum with Linux kernel and Rails, and
has a great story for svn integration, is great on
Linux and Mac OSX, though not so great on Windoze
or in IDEs, yet.
Distributed source code development is great stuff,
especially for working offline - you can take a snapshot
of a SVN repository, make a series of commits offline,
and submit them back to SVN later.
As for migrating the TiddlyWiki development repository,
it seems a little early to consider that, especially
given the strong Tiddlywiki.org/Trac integration and
not knowing how it's positioned against darcs2,
Mercurial, bazar, etc, but it does seem that the
future of source code control is distributed!
If you're interested in git, then mostly as a
thought experiment we put snapshot of the TiddlyWiki
subversion on github:
http://github.com/psd/tiddlywiki/tree/master
.. but with no plans to keep that up to date,
or sync changes back to svn.tiddlywiki.org, yet.
The distributed nature of git, etc, makes them
interesting, possible alternative distributed offline
stores for TW itself.
Thanks to Kerry for an interesting day - slides on all these
topics and others are available on Kerry's slideshare:
http://www.slideshare.net/kjbuckley
and his blog is worth watching:
Daniel Baird
>
> we had a great day in Osmosoft towers with BT Agile guru
> Kerry Buckley, looking at #Selenium, #BDD and #git.
Please consider Mercurial if the TW project goes to distributed
versioning. The git tax on windows is still pretty high.
;D
--
Daniel Baird
/to be or not to be/ => /(2b|[^2]b)/ => /(2|[^2])b/ => /.b/
...optimise your regexes, people!
FND
> versioning. The git tax on windows is still pretty high.
I don't think we'll move away from SVN for the official repo - that
would make it harder for newcomers, and probably wouldn't give us a lot
of advantages.
We can still use Git for local versioning (as I now do - although not
yet for interfacing with the TW SVN repo), that's the beauty of it.
-- F.