-
Notifications
You must be signed in to change notification settings - Fork 113
InstrumentationRunner & test parser key #128
base: master
Are you sure you want to change the base?
Conversation
Conflicts: build.sbt project/plugins/build.sbt src/main/scala/AndroidTest.scala
Conflicts: build.sbt src/main/scala/AndroidKeys.scala src/main/scala/AndroidTest.scala
Conflicts: src/main/scala/AndroidTest.scala
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)].
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
for now i've implemented (some) of this by checking the manifest file: 84d9e1b |
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:
to add specific parser
with scalaTestLogger logging all output to logger: