Skip to content
This repository has been archived by the owner on Oct 26, 2022. It is now read-only.

InstrumentationRunner & test parser key #128

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

charroch
Copy link

@charroch charroch commented May 1, 2012

Jan, I updated the parsing so one could accommodate any parser. It is quite rough at the moment and I intend to rework quite a bit the entire adb logic - relaying on Device rather then processes to run commands. I rather merge with your branch to ensure we are on the same line.

Could you double check it it working as expected on your end. It seems to work fine on mine.

To add specific runner:

  instrumentationRunner in Android := "org.scalatest.tools.SpecRunner",

to add specific parser

  testOutputParser in Android <<= streams map { (s: TaskStreams) =>Some(scalaTestLogger(s.log)) },

with scalaTestLogger logging all output to logger:

   def scalaTestLogger(s:Logger): AndroidTest.TestParser = { i => s.info(IO.readStream(i))}

@charroch
Copy link
Author

any pull on this one?

val action = Seq("shell", "am", "instrument", "-r", "-w", manifestPackage+"/" + inst)
val out = new StringBuffer
val exit = adbTaskWithOutput(dbPath.absolutePath, emulator, s, action:_*) {i => parser.map(_.apply(i)).getOrElse(out.append(IO.readStream(i))) }
if (exit == 0) parseTests(out.toString, manifestPackage, s.log)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a parser gets specified out will always be empty thus failing tests? or the parseTests step would not be necessary.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

out will be empty string and as such will not log anything - as in parseTests is unnecessary. It s the responsibility of the parser to log error. i.e. scalatest will log an error message with an instrumentation code of error. We could have something nicer of Stream[(Int, String)].

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah ok, in which case the parser should get passed in the constructed string and not the InputStream - then either invoking parseTests by default or delegating to the specified parser, which makes the intention a bit clearer and avoid the no-op parseTests which follows.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess there could be a possibility of checking if the setting is set prior to call parseTests. This could be cleaned up but a major refactoring on the device management would be better imo (using IDevice from ddms rather then executing ADB calls). I did not have time to fully look into it yet but playing with the idea. There would be a possibility to have something along the lines of:

executeSQL <= (devices in Android) map { d:IDevice => d.executeCommand(...) }

As such, instrumentation could be used as above and so would logging.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i agree - would be nice to make use of ddmslib for executing commands. there is already some code to initialise the debug bridge / device in AndroidDdm.scala.

@jberkel
Copy link
Owner

jberkel commented Jun 24, 2012

for now i've implemented (some) of this by checking the manifest file: 84d9e1b

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants