Well, now that 0.6 is out, let's try to work out: what next?
There are already a few things on "the plan" for 0.7 - mostly things
I've added because I (personally) think are important, or would provide
a quick-win. See:
http://jira.public.thoughtworks.org/browse/SEL?report=com.atlassian.jira.plugin.system.project:roadmap-panel
But let's think longer-term, too.
In no longer particular order or arrangement, here are some of the
"bigger" things that are on my radar for the months ahead ...
We desperately need some form of automated, cross-platform testing
instructure (SEL-151) to help prevent regressions. My idea was to
leverage the browsers of Selenium users/enthusiasts - just click a link
to run tests and submit results back to the project. Probably a bit a
work, but it should be interested, and will certainly be useful.
Support for testing framed applications (SEL-70) is an oft-requested
feature (it's the only JIRA issue with >1 vote). I think it's about
time we had a go at it.
Speaking of JIRA Votes, I think we should use them more extensively to
gauge how important issues are to the user-community.
Having to crank up a Java Servlet container to test the web-site is kind
of a PITA. Let's ditch it and just generate a static site. I'm
thinking content in a Wiki-esque markup, with some simple templates and
a script to skin things up. I have something like this already - a
Rake+RedCloth+Erb mash-up that I use to generate another site - which
could be easily adapted.
While we're on the subject, I think we need a build-step for the
"javascript" core, which would allow us to (1) concatenate multiple
version-controlled files into a smaller number of distributable
artifacts, and (2) remove duplication e.g. between TestRunner.html and
SeleneseRunner.html, and (2) inject version-numbers. I'd be keen to use
Ruby/Rake there, too.
I'd like to see the "driven-mode" code rationalised: let's concentrate
on one, or perhaps two, driver-languages Is anyone using the .Net
driver? Or the Java driver? Do we need 'em? Can we ditch 'em?
(Sorry, I hope no-one is taking this personally). My preference (in
case it's not blindingly obvious) would to be to concentrate on the Ruby
driver, especially as it seems the most tolerant of changes to the
Selenium core (new commands, etc).
I really don't know much about the driven stuff, but I need to find out.
With people asking for things like conditionals and (*gasp*) "goto" in
the TestRunner, it's become obvious to me that we need to concentrate
more on driven-mode, and make it easier to use. DavidK is part-way
through a refactoring which should make it possible for drivers to
actually retrieve useful data from the browser, rather than just lobbing
it "assert" commands. It would be super-cool if we could support a
Watir-compatibile API.
The "Selenium recorder" sounds pretty promising: I haven't had a chance
to play with it myself, but the buzz has been good. Is there anything
we should do to improve integration between the recorder and Selenium
itself?
Ah, that's enough blue-skying for one evening. I'm keen to hear what
other's think.
--
cheers, MikeW http://www.dogbiscuit.org/mdub/
_______________________________________________
Selenium-devel mailing list
Selenium-devel@lists.public.thoughtworks.org
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-devel
