thanks for your positive comments on twill's syntax: I make it up as I go, and (thus far) have mostly been just happy when something works. I do try to keep the syntax simple as opposed to easy, because one of the major use cases for twill is its use by non-programmers; what programmers find easy is often not so simple. Note also that the twill syntax is very closely linked to Python code; for example,:
translates directly to:
This is a very convenient feature for Python programmers and several users seem to be using it this way.
Also, let me say: twill aims low. I want a simple, solid way to script and test Web sites in a fairly black-box-ish manner. It honestly shouldn't be too much work to get there, and I bet the future will be in recorders and/or test automation technology rather than twill-ish languages. After all, who cares what language the test uses, if the computer can write it for you?
Finally -- Grig Gheorghiu and I have proposed an Agile Development tutorial for PyCon. As you no doubt know, Grig is a huge proponent of Selenium. We will certainly feature both twill and Selenium in our tutorial. No doubt our febrile imaginations will come up with plans for some orcish melange of twill and Selenium, and I have a hard time resisting a good hack...
p.s. "--" for comments is ungodly! long live '#'!
p.p.s. just kidding ;).
I bet the future will be in recorders and/or test automation technology rather than twill-ish languages. After all, who cares what language the test uses, if the computer can write it for you?
I disagree, I think recordings can never understand what matters and what doesn't, and the result is too fragile. And once you've done it, if it's not expressed as some at least vaguely sensible language, then it is uneditable. That language might be in markup, or might not, but I think it really has to be a "language", not just a literal recording. Recorders are nice, still, they just aren't complete by themselves.# Ian Bicking
"Recorders are nice, still, they just aren't complete by themselves."
I agree. Test recorders are kind of like of Ruby on Rails's generators and scaffolding... They both get knocked alot, however, they are very useful when you consider them "the starting point" and not the final production-ready result. Test recorders lower the barrier to entry into the testing framework's language or API--- that, and the kids love 'em. :-) My past experience with macro or test recording is with SQA Robot by Rational (now IBM) and with Microsoft Excel's built in macro utility. In both cases, I used recording to generate a simple, single working script... then went on to edit that raw test into a far more robust and "programmed, not recorded" test suite. The recorders gave me working code from step one, which I then manipulated as needed.
Well, maybe it's a matter of degree. At some point I doubt there will be a need for language innovation -- but recorders can get much better...
We'll see ;).