Please don't nuke the .NET Driver, we're using it extensively to pound
on our ASP.NET app and once its been setup it works brilliantly with
CruiseControl.NET. I don't see a reason to nuke it anyway since it has
not broken between releases so much as just has not had the new
functionality incorporated.
I actually hacked a few more methods into it with the release of 0.6,
that were missing from the code in SVN. I didn't know how to commit them
back or anything, but they'd be trivial to add again (just go through
the command list and do a diff =))
-Greg
Mike Williams wrote:
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.
_______________________________________________
Selenium-devel mailing list
Selenium-devel@lists.public.thoughtworks.org
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-devel
