Bug 24354 - Make the API to set the Options public for the Android NUnit runner project.
Summary: Make the API to set the Options public for the Android NUnit runner project.
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 4.14.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: master
Assignee: Atsushi Eno
Depends on:
Reported: 2014-11-07 16:20 UTC by Jon Goldberger [MSFT]
Modified: 2016-09-20 11:25 UTC (History)
3 users (show)

See Also:
Tags: XATriaged
Is this bug a regression?: ---
Last known good build:


Description Jon Goldberger [MSFT] 2014-11-07 16:20:26 UTC
It would be nice to have an easy way to set the remote server options in code so that you don't have to click on the UI to open and set the Options to send the test results to a remote server in an Android NUnit runner project.

## Workaround option

Use Xamarin.UITest and automate the UI to open the Options page and set the values. This will only work on a simulator unless you have a test cloud account to allow testing on a device.
Comment 1 Andriy 2014-11-10 08:56:56 UTC
Additionally : not only the remote server options but also tests results output format like "NUnit2XmlOutput", "NUnit3XmlOutput".
Comment 3 Jon Goldberger [MSFT] 2015-10-13 14:50:22 UTC
Changing from enhancement to normal as , IIRC, it was said there was no reason for these classes to be internal. 

The classes that should be made public, IMO, are:


With the above classes public, the user should be able to easily set the remote server options in code (like can be done with Monotouch.NUnitLite) and provide a custom text writer to get the results in the desired format.
Comment 4 Atsushi Eno 2015-10-15 03:04:38 UTC
You don't have to open any UI to set those options. "remote", "hostName" and "hostPort" can be specified when you launch the app through standard Android instrumentation. That's what our QA team does.
Comment 5 Atsushi Eno 2015-10-15 03:06:42 UTC
The reason why I didn't make them open is that any stable API will be then required to remain even after we make significant changes (the most foreseeable one is to migrate to NUnit3 once it gets released).

Note You need to log in before you can comment on or make changes to this bug.