support for .side (selenium IDE) project files

[vmchukky]

Based on this weekend discussion with @ptrthomas (would like to start on the journey with a goal to run UI tests from karate in the not-so-distant future)

• trying to support .side (for now only the latest Selenium IDE) project files

• idea is to allow .side file import from karate-ui, auto generate corresponding feature files (each Test Suite maps to one Feature; and each Test Case maps to one Scenario)

• support some dynamic configuration (to be provided not while importing .side file but while running the generated feature files): very rudimentary at this moment (hopefully will get inputs from Peter / community in evolving this)

• need support for running feature-1 calling feature-2 calling feature-3 in UI (may be, we will create a separate ui enhancement issue for Issue-479: karate-ui enhanced to create-new/edit-existing/save-modified features #480 (comment))

• later we can pickup old selenium IDE project files

• couldn't find .side project file format specification (.side-format specification SeleniumHQ/selenium-ide#77); picked a sample .side file to proceed with parsing for now

[vmchukky]

@ptrthomas please review #500 at your convenience

[ptrthomas]

@vmchukky this is very exciting. I made a slight change to the test, it is best practice to output generated files into target so that it doesn't interfere with git managed files

also, I tweaked the generated test and added a test under the junit4 module. because yeah the core doesn't have the http client.

https://github.com/intuit/karate/blob/edeae17011275787d550b83348d7556d85e43e87/karate-junit4/src/test/java/com/intuit/karate/junit4/selenium/sample.feature

I'm proposing instead of url, path may be better - so once a "setup" routine runs and sets sessionPath or some similar variable it just works. do note how karate's path syntax is designed so that you can use comma-delimited strings or variables and you don't need to worry about prefixing the slash character etc.

[vmchukky]

@ptrthomas thanks for taking the PR in.

• the change to target folder makes sense (will keep it in mind)
• Regarding the new SampleRunner in junit4, I was using a TestRunner in the same folder junit4/selenium. Wasn't sure of adding it to PR. Good that you added it.
• Regarding the setup routine, I was contemplating between
  • having the user bring up chromedriver (or some other flavor of webdriver) and provide the URL to us
  • or karate-ui launching (with something like runtime.exec) the webdriver (reading the executable path from some place) as part of setup routine

[ptrthomas]

yes we can work through the setup. it can actually be a java function we write that is intelligent enough to detect the platform, location of chrome (or other browsers in the future) and if it is already running etc. if we look at the selenium / appium projects we may get some ideas.

wdyt about adding selenium keywords to karate just like we have method, request etc for HTTP

with the new engine, I think it may be possible to "register" a set of user-defined keywords. one of the ideas I have is this:

if you have a class WebDriver with many static methods WebDriver.type(Map) you can do something like configure keywords com.myco.WebDriver and then you can do this

# command='type', target='name=q', value='karate'
* webdriver type { target: 'name=q', value: 'karate' }

[vmchukky]

wdyt about adding selenium keywords to karate just like we have method, request etc for HTTP

I like that, that would make selenium keywords first class citizens of karate and makes it easy for all existing selenium tests to use karate (with a simple convert/import utility).

[ptrthomas]

closing this and we can open a new ticket if needed. right now I'm looking at automating chrome directly as an experiment and am thinking selenium using the webdriver spec is a phase 2