DISQUS

Hi. I have had a lot of luck using Hudson with Selenium. However, it was a little tricky to get servers to run Firefox headless and set up X Window frame buffers for the screen capturing.

Also, I see in the article and in comments the mention of setting up a database. I've found that I could remove the database simply for the purpose of testing the way the app works in the browser. In other words, a browser is only needed to test JavaScript. Otherwise you are wasting precious test time. Functional tests requiring a database are easier to do without a browser (HTTP get/post, etc, works on the command line). I gave a talk recently about how I approach Ajax testing:

http://farmdev.com/talks/test-ajax/
http://didenko.com/jschi/090226/

Hehe. I hope now Google is considering implementing a feature that lets admins "preview" the number of sites that will be affected by a change they make to the malware db. In fact, I'm surprised they don't have something like that already. Or maybe they do and said admin was being lazy.

I agree, JavaScript is great. However, you won't be able to use these new features in a website that needs to support all major browsers for, say, 10 years or so :) By that time, Python might even be supported by IE! riiiiight.

My technical post about building Python 3.0 on mac seems to be the most popular all year: http://farmdev.com/thoughts/66/python-3-0-on-ma...

But I had the most fun writing a music piece on DJ Soulpusher who lived in W. Africa for 3 years digging for rare, local funk records from the 70s: http://chicagoindependentradioproject.org/spotl...

Although I agree that "requirements gathering" usually smells of overpaid balding contractors, I've noticed that a software project will quickly fail if there is not a clear specification for how a user should use it. Rather than use the word specification, my company has adopted the phrase User Story. Specifically, we pull a lot of operational theory from the Scrum methodology (http://en.wikipedia.org/wiki/Scrum_%28developme...). Scrum goes so far as to say all User Stories must look like this: "As a <specific user> I want to <perform some action> so that <some value is achieved>." While it is sometimes hard to get these stories right the structure is genius. It forces the development team AND the business to prioritize features better, cut out unnecessary features, and focus on delivering software solutions to the user for business value. If the stories aren't in this structure then they start to look more like "requirements."

I heard recently about a team that had a story, something like "Migrate to new database." This never got prioritized in a work sprint. The business and developers just kept pushing it back putting other stories in front of it. Then, finally someone rewrote the story better: "As a developer I want to migrate the database from Oracle to Postgres so that the business can save hundreds of thousands of dollars per year." Well, guess what, that revised story took precedence over all others ;)

It's also true about having one single visionary. There's another interesting methodology called DSDM (http://en.wikipedia.org/wiki/DSDM). They actually define a role in software development called the "Visionary," a person who is responsible for the direction of the product. This always reminds of the Mac OS X desktop. I read somewhere that there is *one* single person who approves UI decisions. I personally think OS X has a great user interface and if this is true then it certainly proves the importance of making one person (not a committee) in charge of the really hard decisions.

I've found that two things you mentioned here tend to be problematic for functional testing.

First is using an actual interface to setup the data you need to test with. Although this hides the implementation of how your data gets stored, which is nice, it is often slower than necessary. You just need data in the db, right? I actually created a module called fixture to load up just the data for such a test: http://farmdev.com/projects/fixture/ :)

Second, it's not a good idea to insert data in one test that a later test depends on. This is because your tests are no longer modular so you couldn't, for example, re-run only one test that is failing or use a grid solution (like http://selenium-grid.openqa.org/ or like http://code.google.com/p/python-nose/source/bro... -- running tests in parallel with nose).

Hi Matt. As an alternative to Bruce you may want to check out http://code.google.com/p/starscream-slideshow/ (starscream). It's a set of extensions to s5 to do extra stuff. The best of course is source code highlighting which IMO makes for nice code in a presentation. I think s5 actually does a good job at working with screen resolutions. I did this with rst2s5.py and a custom rst directive for the code highlighting (more or less the same as how starscream does it) : http://farmdev.com/talks/unicode/

I recently discovered the builtin plugin --with-id and can't believe I ever lived without it. When it's enabled you get numbered tests so you can re-run individual ones by saying `nosetests 23 45` instead of typing out long path names.

I also miss nosetty, a plugin I wrote a while ago for 0.9 but have yet to port it to 0.10. Quite a lot has changed in stream handling and I started the migration but didn't finish. It was nice because it let you launch an editor at the exact spot in a traceback, especially nice if you need to apply a quick, experimental patch to a system egg.

I also use NoseGAE for testing Google App Engine webapps in-process: http://code.google.com/p/nose-gae/

btw, the official (unofficial?) list of all nose plugins is here: http://nose-plugins.jottit.com/

I agree, Erlang is pretty ugly but I'd love to see some of the OTP (open telecom platform) goodness ported to Python. There are a few comparable packages already but nothing as rock solid as OTP.

And I agree about the perlness of Ruby. This may actually be the one thing holding me back from using the language. Oh what perl scars I've endured! :) Future versions of Ruby seem to be moving past deprecation of the perlness into flatout dropping it completely. I will be much more keen on using Ruby when that day comes.

Now that my memory is jogged ... beyond the perlness, it was the slowness of Ruby 1.8 that turned me off of it. This seems to be changing too:
http://antoniocangiano.com/2007/11/28/holy-shmo...

...which also makes the future of Ruby appealing.

hey, this is great! My grandfather asked me to point him at software he could use to manage a database (for research he was doing). Of course, a day later I gave him a django app to use on my server. But since he is on AOL dial-up he had originally wanted something he could use offline. This would be a perfect solution. Looking forward to it.

(this comment imported into Disqus by Tom Insam on 2008/12/02)