[Enhancement]: Ability to programmically launch Appuim node. Starting AppiumDriver without localhost URL.

[TikhomirovSergey]

I am thinking about this ability.

For the interaction with NodeJS I'm going to use nodyn or trireme. There could be implemented a deamon which would listen to appium events and check state. The end user would have to set value to special system property. This value is a path to node.

Summary: It would look like ChromeDriver, PhantomJSDriver or InternetExplorerDriver.

For now I am extremally busy and will be free by the mid of Febraury'15. So we have time to discuss.

@Jonahss Do you like this idea?

[Jonahss]

Ooh yeah I like this idea.

Make sure there is a way to capture all the Appium log data too. Maybe a method to save the log if the test errors or an exception is thrown. Or automatically save all logs, or access a stream of log lines and deal with them yourself.

We should also check if you are running the latest version of appium and throw a deprecation warning if you are behind.

With adding this amount of customization, would you consider rewriting the java-client from scratch? We could shave off a lot of the complexity added by the Selenium project. It's also confusing to users to continually cast WebElement objects to MobileWebElement objects.

[bootstraponline]

Make sure there is a way to capture all the Appium log data too. Maybe a method to save the log if the test errors or an exception is thrown. Or automatically save all logs, or access a stream of log lines and deal with them yourself.

I already do all this in flaky. Appium is detected via the APPIUM_HOME environment variable.

I think it'd be great if the clients took over some of this responsibility so end users don't have to write extensive test harnesses.

[Jonahss]

It would also be nice to have a better java testrunner that makes
parallelism easier.

On Thu, Jan 15, 2015 at 2:19 PM, bootstraponline notifications@github.com
wrote:

Make sure there is a way to capture all the Appium log data too. Maybe a
method to save the log if the test errors or an exception is thrown. Or
automatically save all logs, or access a stream of log lines and deal with
them yourself.

I already do all this in flaky https://github.com/appium/flaky. Appium
is detected via the APPIUM_HOME environment variable.

I think it'd be great if the clients took over some of this responsibility
so end users don't have to write extensive test harnesses.

—
Reply to this email directly or view it on GitHub
#147 (comment).

[bootstraponline]

I think we'd need a runner for each framework someone could be using. Pretty sure parallelism is different in junit vs testng for example.

[TikhomirovSergey]

Ok @Jonahss
Here are some my remarks:

Make sure there is a way to capture all the Appium log data too. Maybe a method to save the log if the test errors or an exception is thrown. Or automatically save all logs, or access a stream of log lines and deal with them yourself.

I think it is the very good idea. But... Can Appium server return the session logs to the client? Is it possible to capture session log the way below:

driver.manage().logs();

?
I haven't tried it yet. But I can try it later. If appium server can return the session logs we can override methods above.

We should also check if you are running the latest version of appium and throw a deprecation warning if you are behind.

I'm not sure that it is needed. What if some not the latest version is convenient for some developer team?

With adding this amount of customization, would you consider rewriting the java-client from scratch? We could shave off a lot of the complexity added by the Selenium project. It's also confusing to users to continually cast WebElement objects to MobileWebElement objects.

It is difficult to say anything about this point. Actually I think it is good that java-client depends on and extends Selenium libs. I was attracted by Appium at first time because of its compatibility with Selenium. As for me there a few uncomfortable things, they are not crucial.

It's also confusing to users to continually cast WebElement objects to MobileWebElement objects.

Maybe you are right here. Meanwhile it is partially resolved by Appium-specific page object tools. I am going to describe their here: https://github.com/appium/sample-code/issues/30. In another hand it is worth to think about the way which could make it more easier.

Anyway it is another issue:

Here I am going to provide following use cases which would be available for end users:

//the local starting
//when path to the node has been set up at environmental variables/properties

//some more code

new AndroidDriver(Capabilities);
//or 
new IOSDriver(Capabilities);

or

//the local starting
//when path to the node is not set up at environmental variables/properties
System.setProperty("appium property name", "path to the node");

//some more code

new AndroidDriver(Capabilities);
//or 
new IOSDriver(Capabilities);

[Jonahss]

I think it is the very good idea. But... Can Appium server return the session logs to the client? Is it possible to capture session log

I was thinking that if the Appium server is started by executing another process on the operating system, you can just capture the stdout and stderr of the new process.

I'm not sure that it is needed. What if some not the latest version is convenient for some developer team?

There should never be a reason to use an older version :( A lot of people do use older versions and whenever they have a problem, the first answer is always "use the latest version". The feature isn't super important though, so we can leave it out.

Your plan looks good to me

[TikhomirovSergey]

There should never be a reason to use an older version :( A lot of people do use older versions and whenever they have a problem, the first answer is always "use the latest version". The feature isn't super important though, so we can leave it out.

Ok. We can permit to users some version. But it should be the lowest required server version for some new released client if there are major changes. It is like chromedriver. It depends on version of Chrome/Chromium tools.