Encapsulate element and its methods. Replace direct use of FrameworkElement and extensions. See https://github.com/2gis/Winium.StoreApps.CodedUi/blob/master/Winium.StoreApps.CodedUITestProject/WiniumElement.cs for example.

Similar to Appium's --pre-launch

Pre-launch the application before allowing the first session (Requires –app and, for Android, –app-pkg and –app-activity)

This will be useful for unsupervised CI test runs on virtual machines (which are slower than bare hosts, resulting in remote procedure call failing in xde or smartdevice connectivity due to timeouts)

This can be used to

• reset state of app between tests in same session to speed them up if tests require uploading big files, etc.
• test app state resuming

Currently we cannot find and return popup child root element to tests as we start searching from it and only consider his descendants. Meaning that we cannot locate ContentDialog by class name as it is a popup root element, but we can locate all his descendants, this might make searching for such standard popup elements and distinguishing between them unnecessary complicated.

Popup child root elements should be included in search.

Appium has reimplemented touch actions to be more useful and easier ot handle on mobile apps. All actions are packed in single message and sent over the wire. For reference, see from appium.webdriver.common.touch_action import TouchAction in python bindings or https://w3c.github.io/webdriver/webdriver-spec.html#actions-endpoint

Add timeouts to all forwarded commands, so that if the app crashes. Driver will get timeout earlier and will be able to respond to client with error, instead of making a client to wait for a big default timeout.

Add commands to switch phone network off, set it to different speed limits, etc.
See related sections in:
https://github.com/SeleniumHQ/mobile-spec/blob/master/spec-draft.md#value-alias-------data--wifi--airplane-mode-
https://code.google.com/p/selenium/source/browse/spec-draft.md?repo=mobile#104

XPath or similar (css selector-like) locator strategy might be useful for apps that have complex UIs or not quite tuned for ease of testing.

1. XPath locator can be already implemented in driver based on PageSourceCommand and standard XmlDocument, but it will require PageSourceCommand to be modified in a way that it will save all elements to registered elements storage. Such solution is easiest for implementation at the moment, but will be very slow as it will require whole UI visual tree to be traversed and represented as XML nodes regardless of actual XPath, which can match first node.
2. Implementing custom XmlReader, that would return nodes on the fly as needed, might be a better option in terms of performance. See Implementing XmlReader Classes for Non-XML Data Structures and Formats.

Add server deviceName capability which will enable users run tests in parallel as in Appium by launching n instances of driver listening on different ports with different deviceNames specified for each.

@jimevans gave and idea on how we could implement automatic InnerServer injection into the AUT. If implemented, then there will be no need to manually add InnerServer to your app code and have a special configuration that you have to build especially for automated testing.

An example demo project for xap files can be found here https://github.com/jimevans/InjectedCodeDemo.
For appx you can't simple unzip it and zip it back, you will have to use MakeAppx and SignTool for signing and unpacking/packing.

Currently, the IsUserVisible function checks IsHitTestVisible but I'm not sure it should. IsHitTestVisible is a bit of a misnomer. It doesn't actually say anything about if the element is visible or not. It just says whether you can interact with it. It is true by default. Documentation here : https://msdn.microsoft.com/en-us/library/system.windows.uielement.ishittestvisible(v=vs.110).aspx#NotExistJustToMakeTheAElementVisible

We did a few tests with removing IsHitTestVisible from IsUserVisible. It works in most cases. The only case it didn't work was a case where we generate the components in the .cs file, rather than defining them in the XAML file. In this case, the driver would successfully get the correct coordinates and click at that position. But somehow the element wasn't ready and nothing happened. Since the driver just clicks a position, it reported a success and the test moved on to the next step Which of course failed because our application never reacted to the click. We also tried checking HitTestVisible with the .attribute command through Winium before clicking. But it reported it to true so that wasn't much of a help either.

It was working before we removed IsHitTestVisible, so when we debugged IsUserVisible we found that the IsHitTestVisible was set to false, even though we never set it ourselves. I'm not sure why this happens. But we found a workaround by implementing retry functionality for every step of the test.

So removing IsHitTestVisible would be the logical option, but here is still a chance that this might fail other tests. Otherwise there is no reason to use it as far as I can see. If you wanted to check IsHitTestVisible, you should use the .attribute() command.

AppBarToggleButton does not support invoke pattern and could not be clicked due to AppBar coordinates mixup.

Add support for TogglePattern via ExecuteScript with automation: toggle.
See more at msdn

Rarely after deploying app and uploading files to app storage an "Unknown error: The remote procedure call failed." might occur when trying to launch app.

This only happens on build machine that is under hard memory and hdd usage, does not happen on dev machines that usually run tests faster. Might be related to some inner timeouts in SmartDevice API.

Possible hot fix: simple retry launching app a few times until some timeout is reached. Yet it would be better to research why exactly such exception is raised inside SmartDevice API.

New sessions fails to start because AutomationClient is unable to connect to emulator by name if user name is not in lower case.

new XdeWmiFactory().GetVirtualMachine(Name) looks up for VM using case insensitive matching and returns VM with a name set to the one that was passed in (so that the actual VM name might have different case). But AutomationClient.CreateAutomationClient uses case sensitive matching to find the emulator. This means that we either have to:

1. lower case user name before appending it to VM name,
2. or we should use new XdeWmiFactory().GetAllVirtualMachines(settings) method to get a full list of emulators with a names in correct case.

• Option 1 is easy fix, but we might get into some another case problem in the future.
• Option 2 should be more robust and preferred if it does not hit performance.

EmulatorController.cs#L205-L208, EmulatorController.cs#L40-L41

Add command line option to register the driver as a node for Selenium Grid

https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/element/:id/enabled

Драйвер возвращает ответ на любой запрос кроме создания сессии с null значением поля SessionId. Из-за чего биндинги не могут его распарсить.
Ниже приведены списки команд и ответы от ChromeDriver

• CreateSession
  {(45c49ade8e122a00a6d00e3a3dd8e098 Success: System.Collections.Generic.Dictionary`2[System.String,System.Object])}
• GoUrl
  {(45c49ade8e122a00a6d00e3a3dd8e098 Success: )}
• FindElement
  {(45c49ade8e122a00a6d00e3a3dd8e098 Success: System.Collections.Generic.Dictionary`2[System.String,System.Object])
  То есть на каждый запрос ChromeDriver возвращает значение идентификатора сессии. Возможно это верно ещё и потому, что есть возможность работы с несколькими сессиями.

Т.о. нужно добавить значение SessionId в ответ на любой запрос к драйверу

See http://stackoverflow.com/questions/2441290/json-serialization-of-enum-as-string for how to serialise enum as string using Json.NET

Calling

var openNextScreen = new TouchActions(Driver);

throws exception

exception (An exception of type 'System.ArgumentException' occurred in WebDriver.dll but was not handled in user code  |  Additional information: The IWebDriver object must implement or wrap a driver that implements IHasTouchScreen.

Probably driver should return some kind of special capability to indicate to C# bindings that it can do touch actions.

When I try to access the Enabled property of a component, an exception is thrown. Should I perform some configuration or extra implementation for this to work?

https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/element/:id/size

Use something like existing ping and low timeout

Currently SendKeys and SendKeysToActiveElementExecutor is separated into two steps:

1. Extract regular keys from value and send to InnerServer to be set on element text property using automation (not even close to input simulation).
2. Send special keys using emulator API (actual input simulation)

Using AutomationClient.CreateAutomationClient(this.emulatorVm.Name).InputPipe.SendText will simplify keys sending, as it will require execution only on Driver side (no code in InnerServer). Also, it will let us fully implement send keys as they should be, including ability to send Backspace and other special keys at any moment of text input.

Making innerPort dynamically assignable from predefined range and including innerPort auto-discovery will greatly simplify parallel execution of tests on different emulators.

Currently to run tests in parallel on same machine one would have to:

1. build n copies of .appx, but with different innerPorts,
2. start n copies of driver,
3. start n sessions against each driver with different innerPort capability.

All this hassle with innerPort is caused by the fact that emulators do forward their port to localhost. Maybe there is another way to deal with it, for example modifying Hyper-V machine settings or switch in someway, but it seems more invasive.

Adding port discovery will let us get rid of step 1 completely and simplify step 3.

We can take element screenshot using RenderTargetBitmap
http://social.technet.microsoft.com/wiki/contents/articles/20648.using-the-rendertargetbitmap-in-windows-store-apps-with-xaml-and-c.aspx

We can also replace takeScreenshot impl (using emulator controller) with RenderTargetBitmap one, as it should work both for emulators and devices.

This will allow to access complex properties like dictionaries, lists, etc.

Should be QuitExecutor.cs

• Server --Proxy request--> Inner Server (same as it is now)
• Duplex Socket Server <----> Web Socket Client (simplifies code on the phone side)
• File based communications (solves the problem of #67 network throttling killing communication, but introduces polling)

2gis/winphonedriver/issues/53

Currently PageSourceCommand returns only few base attributes of WiniumElement. If extend it, we can display in Inspector additional properties depending on the type of FrameworkElement.

For example, if FrameworkElement is TextBox, then add FontSize, FontStyle, Foreground and other Windows.UI.Xaml.Controls.TextBlock properties.

Currently we use custom mix of JSON RPC and HTTP to communicate between Driver and InnerServer, it has it roots in older implementations, where Driver forwarded HTTP requests to InnerServer without processing. But now it makes code hard to understand and maintain as we have tow hacked HTTP server implementations based on TcpListener and StreamSocketListener (because TcpListener is not supported in StoreApps).

Replace custom mix of JSON RPC and HTTP with clean and simple JSON RPC implementation.

Profile session start. It seems that GetEmulatorVm

Maybe it can be done async with device connection and app deployment in InitializeApplication.

Once #57 is done, we could research a possibility of transitioning from InnerServer being a StreamSocketListener to it being a WebSocket client which will start establish duplex connection to a driver on start.
This will let get rid of custom HTTP code on InnerServer side and generally simplify InnerServer. It will also allow us to implement some advanced features, that might require a two-way connection. But this might require a more complex implementation on Driver side for NewSession command which will have to wait for incoming InnerServer connection while blocking response to test client (NewSession should return response to test client only once the InnerServer started and established connection).

https://msdn.microsoft.com/library/windows/apps/br226842

Support for testing of hbrid apps can be done in the same way as it is done in Appium.
We can implement switching between contexts. When in WebView context driver will simple proxy commands and execute InvokeScript on WebView.

Here are docs on InvokeScript https://msdn.microsoft.com/en-us/library/windows.ui.xaml.controls.webview.invokescript.aspx

Also, there is a project of selenium-based driver for Windows Phone internet Explorer:
https://github.com/forcedotcom/windowsphonedriver
This project includes driver, that proxies commands and test app, that has single WebView. commands are executed using InvokeScript and selenium atoms.

Click will fail If one tried to click element that is still animating. Either click command should wait for element to stop animation or there should be a command to explicitly wait for animations to finish. Preferable both.

Currently system locale is used for emulators. It would be useful to be able to set locale for session.

This is already implemented in Winium.StoreApps.CodedUi. Although there is seems to be some problem with requesting different locales in consecutive sessions.

After making winium setup ready. which looks like

The driver is running on port 9999 and test automation server under test in installed i.e by placing "AutomationServer.Instance.InitializeAndStart();" this in AUT Code and also added reference to Inner Server in AUT project

And on running the TestCase getting an error which looks like

As i am trying to run my First Test Case using Winium . Am i missing soemthing ? Please help me out.

Winium.StoreApps.InnerServer is portable, i.e. it targets both Windows and Windows Phone. InnerServer should target only Windows Phone as it is only used in WP apps, and, also, to reduce any possibility of confusion of the purpose of this package on NuGet.

Driver should support setting the amount of time the driver should wait when searching for elements. Currently it fails on first try if no element was found and end user has to use explicit wait from bindings.

Coordinates returned by location command and used by click command are incorrect when apps screen slid up due to some input being focused, e.g. AutoSuggestBox, which leads to driver tapping incorrect screen point.

See AutoSuggestSample.cs. Replacing temporary execute script solution with suggest.Click() in test case will result in incorrect tap.

Possible solution: use GetClickablePoint for all elements that support it instead of current screen point calculation algorithm.

Simple replacement of location algorithm with GetClickablePoint resulted in test_automation_scroll failing, needs further investigation.

To integrate driver with Selenium Grid constant session name AwesomeSession must be replaced with uniquely generated one for each session.

https://github.com/2gis/Winium.StoreApps/blob/c35b2aefde404ce208718b08d1aa18634fd62920/Winium/Winium.StoreApps.Driver/Automator/Automator.cs#L92
https://github.com/2gis/Winium.StoreApps/blob/c35b2aefde404ce208718b08d1aa18634fd62920/Winium/Winium.StoreApps.Driver/CommandExecutors/NewSessionExecutor.cs#L23

Orientation command is broken since transition to StoreApps from Silverlight.

https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/orientation

Commands can be implemented using Microsoft.Xde.Interface.AutomationClient.