Open jamiejackson opened 8 years ago
Makes sense to me. I think I probably did it this way for my local environment which never used the original. Better to not break everyone's existing tests 😀
@Lampei, I'm confused about something:
This decides whether to use webSelenium
or selenium
, depending on arguments.
Whereas the v2 (WebDriver) tests seem to invoke selenium
, not webSelenium
.
Can you explain?
I was trying to write something up in the readme.md about how to use one or the other, but I got stuck trying to understand the existing code.
@jamiejackson I think you are just seeing a poorly named class at the time. I'm not sure why I named it Web selenium as that appears to be the old code, right? Selenium is the new Web driver. I think I actually confused myself at times with the naming.
Oh, that is confusing, but I see now. selenium.cfc
=WebDriver and webSelenium.cfc
=RC.
My first reaction would be to rename webSelenium.cfc
to selenium.cfc
(for backwards compatibility for folks who were invoking it directly), and rename selenium.cfc
to WebDriverSelenium.cfc
, or similar.
Thoughts?
Yup. Default to backwards compatibility first again. Definitely try to disambiguate it (seeing as both you and I know what's going on and we're still getting confused by it)
Now that I'm actually integrating @Lampei's/my pull request into a project, I notice a change that enables WebDriver ("version 2" mode) by default.
That means that existing tests will often fail, because RC and WebDriver don't have all of the same functionality.
Here's an example from ValidateThis (a consumer of CFSelenium):
The
super
call would need to be changed to point back to the old version, in order for tests to work:It might have been better to preserve seamless backward compatibility by defaulting to v1 (RC), then folks could upgrade, when they see fit, to v2 (Webdriver) by changing their
beforeTests()
accordingly.@Lampei, @ddspringle, et al,, thoughts?