Python community is extremely active in building agile testing tools

If you are a regular reader of Titus Brown’s blogs then you wont believe that Titus Brown is a biology graduate and is working on molecular developmental biology, genomics and bioinformatics. His ultimate goal is to be a professor, working on interesting things and molding young minds . Programming is his hobby, he enjoys a lot of programming and hacking. In this interview he talks about Twill as well as his Python based projects like Cartwheel, FamilyRelations and PyWX. He also tells us his views on Agile Development and Testing In Python. If you are a ZOPE user then you will definitely like to read his explanation on “Zope is evil”.

PythonThreads >> Hello Titus. We are glad to have you on PythonThreads. Could you introduce yourself?
Titus Brown >> Thanks for inviting me!

Officially, I’m a biology graduate student at Caltech. I work on molecular developmental biology in Eric Davidson’s lab; we study the molecular mechanisms underlying the development of sea urchins from egg to larvae.  (There are some pretty pictures at www.its.caltech.edu/~mirsky/; check out the Network, especially.)  In addition to wet-bench experiments, I also have done a fair amount of genomics and bioinformatics work, doing things like building tools to find the information that controls gene expression.

My undergraduate degree is in Math, from Reed College (www.reed.edu). I started doing research right after my first year at Reed, when I came to Caltech to work with Chris Adami and Charles Ofria on Avida (dllab.caltech.edu); since then I’ve also worked on Earthshine, a really cool project where we use the moon’s surface to look at the reflectivity of the earth (www.bbso.njit.edu/Research/EarthShine/).

I will be getting my PhD any day now; I’m just waiting on some experimental results. Once I get my PhD, I’m planning to move into chick developmental biology, studying midline development — basically similar to what we study in the sea urchin, but in a more complicated organism.

My ultimate goal is to be a professor, working on interesting things by day and molding young minds by night. Unofficially, I do an awful lot of programming, almost entirely for fun.  These hobbies do have a way of turning into work: my Web stuff turned into a lot of the bioinformatics stuff I’ve done, twill turned into the whole agile testing project, etc.  I *do* enjoy hacking on stuff informally, despite all of this — things just get out of hand.

“I do an awful lot of programming, almost entirely for fun ….”

PythonThreads >> Could you tell us about the features of Twill and how it can be useful to the software developer community, particularly Python developers?
Titus Brown >> twill implements a really simple concept: a scripting language for browsing the Web that lets you do things like fill out forms and manage cookies.  It’s not connected to any browser, and because it’s written in Python, it’s entirely cross platform. It was based on the old PBP project (by Cory Dodt), which I took up because I needed to write automated tests for a pair of increasingly complex and brittle Web projects(collar and Cartwheel).  So I initially developed it for testing. It quickly got picked up by non-testers, though, because it was a simple way for Python developers to script Web crawling and scraping.  This has led to some tension in the future goals for twill, which has been interesting for me (and probably frustrating for everyone else to watch!).

“twill is a simple way for Python developers to script Web crawling and scraping …”

Paranthetically, let me say that twill works really for only one reason: John Lee’s mechanize, which is a fantastic library for browsing the Web via Python.  John does 95% of the hard work of grokking the hideously nasty bits of HTTP, and I just give him bug reports periodically when stuff doesn’t work! twill, and the other programs like it for other languages, make it not only *possible* but *easy* to test Web sites and to build automated test suites for Web projects.  That’s really the main attraction for me.

“John Lee’s mechanize is a fantastic library for browsing the Web via Python ….”

As I said, it’s also proven to be really useful for things like scraping sites that don’t want to be scraped, e.g. Petrik De Heus’s Wikipedia Watch List to RSS Feed software (http://www.deheus.net/petrik/blog/post/68/). I wish Web developers would just realize that they need to provide an open remote API for their Web sites, but that seems a distant goal. The neatest aspect of twill — to me, anyway — is that it just works. There’s relatively few features to configure; cookies, redirects, etc. all “just work” — or at least they should!  It’s potentially usable as a component for building future work, too, but it gets you 80% of the way with about 20% of the effort.  A good first step ;). The second neatest feature of twill is the extensions mechanism. Check out the “link checker” extension module for a neat application of this.  So far I’ve been the author of most of the extension modules.  I’m hoping that will change as people realize that it’s a good way to extend twill to fit their own needs.

“Web developers would just realize that they need to provide an open remote API for their Web sites ….”

PythonThreads >> How do you see Twill evolving in the short and long term? Is there any possibility for twill to handle JavaScript in the future?
Titus Brown >> Short-term, I’d like to see better documentation, more tests, and a recorder.  That’s what’s on the menu for 1.0 (the current version is 0.8.5, I think). Long-term, I’d like to see some sort of optional integration with browsers — e.g. via PAMIE/PyXPCOM or Selenium driven mode.  I’m not sure how to feel about JavaScript; right now I’d basically have to write that myself, or find someone really enthusiastic to handle the technical details while I figure out how to integrate it into twill.  (I think a pure-Python JavaScript interpreter would be fantastic, although perhaps not as useful for *testing* as integration with the Mozilla JavaScript library. Perhaps one or both of these could be a Summer-of-Code project, hint hint.).

Bottom line, I just don’t grok JavaScript enough to know how it could fit into twill, and I don’t use JavaScript much myself. Clearly both things will change in the future…

“A pure-Python JavaScript interpreter would be fantastic ….”

PythonThreads >> Could you tell us more about your experience with Python while working on your other projects like Cartwheel, FamilyRelations and PyWX projects?
Titus Brown >> PyWX was my first Python project.  Brent Fulgham, Michael Haggerty, and I implemented a bridge between the C API for AOLserver and the Python interpreter.  It was a great way to learn Python, if a trifle roundabout.  It gave me immense respect for the core C code in Python, which is quite clean and clear compared to most other C code.

“PyWX gave me immense respect for the core C code in Python ….”

FamilyRelations was a Jython project that I developed for bioinformatics visualization.  Jython was great, if more than a bit slow; the ability to use the Java libraries, esp. the Swing GUI library, was fantastic.  I moved the project into C++ for three reasons: I needed to use FLTK (www.fltk.org), a nice light little cross-platform GUI library; speed — fast code is just easier to write in C++ than in Java; and footprint — Java is a huge memory hog.  I have no regrets about the move to C++, although if I had a few weeks I’d try wrapping my custom widgets with PyFLTK and rewrite my higher-level code in Python.

“fast code is just easier to write in C++ than in Java, Java is a huge memory hog ….”

Cartwheel was one of the two projects that motivated twill.  It’s a large-ish Web site and compute framework for running bioinformatics analyses, and the Web site, in particular, is getting brittle. I really really really want to write a test suite for it, but that will have to wait ’til I have a solid week or two.  (I also need to upgrade Quixote from 1.x at some point!)

There are two unifying experiences from these projects: Python plays very nicely with other languages, and I code in Python at least 10x faster than I do in any other language.  This is one of the things that has led to an explosion of projects, for me.

“I code in Python at least 10x faster than I do in any other language….”

PythonThreads >> While most believe that Zope is the best thing to happen to Python, you have said that “Zope is evil”. Could you elaborate? What are your views on Zope’s contribution in the growth of Python.
Titus Brown >> Google’s great, isn’t it?

The “Zope is Evil” page was written in response to an *incredibly* frustrating set of experiences I had back in 2000.  First of all, I was trying to get into using Python for Web stuff, and a commonly query/response in comp.lang.python was “I need to write a Web page…what should I use?” followed by “Zope!”  This kind of response is frankly silly, although it has since been outclassed by the response [“use X” for X in getPythonWebFrameworks() ]. Second of all, I wanted to play with Zope and maybe get it working with our PyWX code. So I sat down and tried to get into Zope and got very frustrated. Among the complaints I had were documentation that couldn’t be read on-line (hello, it’s a Web framework!!), and an incredible proliferation of cute Z-words.  (You can read the page at http://zope-is-evil-666.idyll.org if you want more details.)

“the complaints I had were documentation that couldn’t be read on-line….”

I hear that Zope has improved dramatically since then, and I look forward to one day trying it out again. At PyCon 2002 I sat next to Paul Everitt at lunch one day.  That was kind of embarrassing — he clearly knew who I was (and what I’d written) but was very cool about the whole thing.  That, and one or two other incidents, has led to a general moderation of my posting of snarky comments online — remember, they *will* find you ;). A more general theme that may illuminate the “Zope is Evil” page is my dislike of dishonest hype.

“Zope is Evil” page is my dislike of dishonest hype ….”

Recently, we’ve seen Ruby on Rails take up the “killer app” standard for Ruby, and a lot of guff has surfaced about domain specific languages and how “Ruby is better” for everything under the sun. Bushwah. The most that any generic app or app framework can do is canalize software development in certain ways: it may be very, very easy to write certain types of Web apps in RoR or Zope or Plone or Django, but ultimately there’s got to be something that *distinguishes* your app from the rest of the apps out there, right?  The distinctive bit is what people will actually spend their time on once they get past sessions, tying forms to the database, and the other things that everyone does with their Web app.  That distinctive bit is going to take more than 80% of the effort, and no framework under the sun is going to automate that for you.  So why pretend that one will? I think it’s basically dishonest to assert that framework X, language Y, or approach Z is going to solve your problems. They’re not, in general.

“it’s basically dishonest to assert that framework X, language Y, or approach Z is going to solve your problems….”

I think a more honest approach for Zope and RoR would be to have said something like, “hey, this is what we’re good at.  this is what we’re probably not good at, although you can still do it.  here’s a tutorial.  go have fun.”  Instead we get overblown polemics (on both sides, yes 😉 claiming things one way or the other.  It reminds me of the religious arguments I read about, frankly.  Not very enjoyable to watch, although participation can be cathartic in a certain way.

“we get overblown polemics claiming things one way or the other….”

PythonThreads >> You recently presented on “Agile Development and Testing In Python” at Pycon 2006. How big is Agile development and Testing in the Python world?
Titus Brown >> Immodestly, I will say that our tutorial was extremely well attended. I think it filled up twice as fast as any other tutorial, and I bet we could have gotten 60 or 70 people (instead of 40 or so) quite easily. That having been said, I feel like we were perhaps in the position of a Catholic minister at Christmas, swamped with parishioners for that one day.  Everybody knows they need to do testing, and perhaps they were hoping that the tutorial would magically grant them with tested code.  Sorry to disappoint ;).

“they were hoping that the tutorial would magically grant them with tested code….”

Regardless of *use*, the Python community is extremely active in *building* agile testing tools.  Check out the Python Testing Tools Taxonomy, http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy, for the proof!  I can’t speak to whether or not Python is abnormally active in this area or not, although I feel certain that any community as clued in as the Python community is avant garde in this respect, too.

(Note that my partner in the tutorial was Grig Gheorghiu, known for his extremely useful agile testing blog, agiletesting.blogspot.com, as well as the tools taxonomy.  Whatever I know about agile testing terminology comes from him, and whatever I get wrong is almost certainly due to my own lack of understanding.)

“the Python community is extremely active in building agile testing tools….”

PythonThreads >> Could you list 3 things that you find most impressive about the agile way?
Titus Brown >> Rapid prototyping, testing at all levels, and short iterations.  I consider “rapid prototyping” to be an excellent alternative to “big design up front”, and I consider “short iterations” to be a good solution to the sort of large-scale breakage that occurs between releases in many projects.  Testing at all levels should go without saying: unit tests say nothing about UI functionality, and neither do functional tests; acceptance and regression tests are beasts that will catch other problems than functional and unit tests.  Test from as many directions, at as many levels, as possible.

“unit tests say nothing about UI functionality….”

PythonThreads >> Some believe that with Agile Testing there’s no need for a separate testing team. The developers are the testers. While others feel that the agile guys are taking a very narrow approach to testing. Where do you stand on this?
Titus Brown >> Dogmatism is bad, and anybody who asserts that there’s *no* need for a separate testing team is probably smoking something fun, or is a consultant looking to make some money fixing your problems.

I’ve rarely come across a situation where additional perspectives were bad, and that includes testing.  That having been said, I firmly believe that the best code-facing testers are also going to be moderately serious developers (or at least people with that potential).  However, developers are typically disastrous at UI testing, and I can’t even imagine letting the dev team design the acceptance tests.  Some sort of exploratory testing is usually a good idea, too, and that can be done by anyone. So my succinct answer is this: were the agile guys truly saying that there’s no need for a separate testing team, I’d think they were taking a narrow approach.  I think it’s a straw man argument, however, and discussion on the agile-testing list supports this: there are many wise and experienced testers on that list who would be skeptical of that argument!

“the best code-facing testers are also going to be moderately serious developers ….”

PythonThreads >> In your experience, what are the primary advantages of a Test Driven Development (TDD) approach as compared to older techniques?
Titus Brown >> Grig may shoot me for writing this down, but I have a really hard time with TDD myself; it doesn’t fit my brain. I prefer what Grig named “Test Enhanced Development”, where code may or may not be *developed* with tests, but tests (at all levels — unit, regression, acceptance, etc) are added throughout the development process.  This could be because I tend to code *really* fast when starting a project, and then rewrite large sections of the code (within a few hours or days) as I figure out what I need to do.  Writing tests first would add serious overhead, although I suspect TDD advocates might suggest that I wouldn’t need to rewrite code if I did it their way.  Whatever, I’m not doing it their way and I’m not planning to change soon — maybe next year ;).

“I tend to code really fast when starting a project ….”

One particularly useful procedure of both TDD and “TED” is to write unit tests for each new bug found: this lets you precisely identify the source(s) of the bug and also ensures that it never re-occurs!  I embraced agile testing as a force multiplier for my own research projects, and this is really its continuing utility for me.  Since I mostly work alone and simultaneously on many different research projects, I use the tests to prevent “bit-rot” in my own software and also use them as enforceable API documentation.  I’m sure this is a sloppy set of habits, but again, it works fairly well for me!

So, succinctly, the advantages (for me) of a TDD-like approach are that it serves as enforceable API documentation, stops bit-rot in the parts of the software you’re not focused on, and kills bugs permanently.

“I use the tests to prevent “bit-rot” in my own software ….”

PythonThreads >> Any ongoing Web application Testing / Unit Testing related developments that you are watching with particular interest?
Titus Brown >> Gosh.  I’m really looking forward to seeing Selenium v1.0, twill v1.0, nose v1.0, buildbot v1.0, etc.  Right now I feel like the tools I use — including twill, sadly enough — are only half-working and half-documented.  I also think some good docs (perhaps in the form of how-to books) about getting all of this stuff up and running would be well-received, but … more on that later ;).  So I’m mostly looking forward to technological refinements of what we already have; what’s there works OK, and we need to get people using it.  (The real battle is social, of course, and that’s where being a professor could come in handy…)

“I’m looking forward to technological refinements of what we already have….”

PythonThreads >> You have spent a lot of time on Python but you have also tried out various other languages. I noticed that you even wrote 5000 lines of Java for a Sun Java contest. Do you prefer Python? If yes, do you think Python has an edge over other languages?
Titus Brown >> A brief history of projects: I worked on Dominion (a curses-based Empire-like game) and Avida in C, then rewrote Avida in simple C++, used Tk/Tcl to write a GUI for Avida, learned Java to rewrite Avida for the Sun Java contest, learned Perl to do some scripting and write a large-ish Web site, re-learned Tcl for use with AOLServer and the ArsDigita Community System, and then picked up Python.  I’ve never looked back.  (You can credit Mike Vanier with pushing Python on me, incidentally; Mike is currently teaching a multi-language course at Caltech that I highly recommend to Caltech students.)

“After picking up Python, I’ve never looked back….”

For me, the two biggest advantages Python initially had were readability — most any programmer can understand simple Python code in a very short time, which is not so true for other languages — and reusability.  I don’t know what exactly it is about Python, but I started reusing my Python code almost immediately.  This had not happened with any of the previous languages; there, re-use occurred primarily through cutting and pasting, not library building.

There are lots of other nifty Python features that I like, but most of them are shared with other languages.  For example, it’s really easy to wrap C code with Python and Tcl; graphics are pretty simple with Tk, whether you’re using Python or Tcl; string processing is very easy in both Perl and Python, as is writing simple Web pages; the Java GUI libraries are great, and accessible with both Java and Jython; etc. FWIW, I do know that other people have had different experiences. I’m sure that for some people the Perl/C API is simple and obvious, but for me it’s really non-intuitive.  I suspect string processing in Tcl is simple, given the way the language works, but I never “got it”. Perl must have some great GUI libraries, etc.  Python’s just got a good intersection of features that matches what I generally need to do.

“any programmer can understand simple Python code in a very short time….”

I am interested in checking out Ruby, despite the hype factor; I don’t feel that I can honestly put down a language without having written a few thousand lines of code in it ;).  I’m even more interested in trying out Scheme, OCaml and Haskell.  Most of the really serious CS students I know swear by one (or all) of them.  (I did have one fairly clued-in CS student recently tell me that PHP was a fantastic language.  I’d never heard that before, and I’m not sure what to make of it.  I have heard serious people tell me that Perl is fantastic in some pretty deep ways, which is more believable.)

“I’m even more interested in trying out Scheme, OCaml and Haskell….”

PythonThreads >> Thanks Titus. It’s been good talking to you. Could you share your blog url or email address with our readers?
Titus Brown >> You can read my diary at http://www.advogato.org/person/titus/, or contact me directly at titus at idyll dot org .  (Spammers welcome, obviously.)  I’ve also set up a Web space at http://ivory.idyll.org/ that I hope to expand and extend. Advogato doesn’t allow for diary comments for the moment, but I’m always happy to post your comments and/or link to other blogs if you have something to say.  Just send me an e-mail.

BTW, people in the LA area should come to the socal-piggies meetings. They’re fun.