This adds a flag to |mach robocop| that does everything to run a
Robocop test except launch the actual test. Instead of launching the
test, it starts the mochi.test server and launches Fennec with a test
profile; then it sits and waits forever.
This allows regular Java IDEs (IntelliJ, but previously Eclipse) to
run Robocop tests like regular instrumentation tests, "injecting" them
into the prepared testing environment. It's quite nice!
--HG--
extra : rebase_source : a5ab08222110a20291aebe70ef1fda0d340dbe7d
extra : source : e91ac9a35f86928fcd519911476ee7d68d06f921
This adds a flag to |mach robocop| that does everything to run a
Robocop test except launch the actual test. Instead of launching the
test, it starts the mochi.test server and launches Fennec with a test
profile; then it sits and waits forever.
This allows regular Java IDEs (IntelliJ, but previously Eclipse) to
run Robocop tests like regular instrumentation tests, "injecting" them
into the prepared testing environment. It's quite nice!
--HG--
extra : rebase_source : 15e9e8d5c311312e2eb317936e5d154237c1f9a3
extra : histedit_source : 050ac958ae8580f45e5011a0d353bf13e65d5ff3
Now that defining $DMD is no longer necessary to run DMD, this patch does the
following.
- Removes all the places where we set DMD=1 (test harnesses, etc.)
- Still handles DMD=1, for backwards compatibility.
- Prints "$DMD is undefined" at DMD start-up if appropriate.
- Writes a |null| value for |dmdEnvVar| in the JSON if $DMD is undefined. Bumps
the DMD output version number accordingly.
- Changes a bunch of the test files accordingly, including changing the mode of
script-ignore-alloc-fns.json in order to test a case where $DMD is undefined.
--HG--
extra : rebase_source : eb1ef5722410734ce6d7658465ff6f442ee4ed49
On my local testing devices, |adb pull| complains about not being able
to read /data/anr/traces.txt but the command succeeds. The subsequent
local file read produces an IOError. This ignores that exception.
Under normal circumstances this should be created automatically inside the
profile directory when we first start, but this won't happen if we fail
to start properly altogether. If that's the case, we've got other problems
that will be reported as errors. Let's just print a warning so we don't
misdiagnose the problem under those circumstances.
It turns out that relying on the user to check return codes for every
command was non-intuitive and resulted in many hard to trace bugs.
Now most functinos just return "None", and raise a DMError when there's an
exception. The exception to this are functions like dirExists, which now return
booleans, and throw exceptions on error. This is a fairly major refactor,
and also involved the following internal changes:
* Removed FileError and AgentError exceptions, replaced with DMError
(having to manage three different types of exceptions was confusing,
all the more so when we're raising them)
* Docstrings updated to remove references to return values where no
longer relevant
* pushFile no longer will create a directory to accomodate the file
if it doesn't exist (this makes it consistent with devicemanagerADB)
* dmSUT we validate the file, but assume that we get something back
from the agent, instead of falling back to manual validation in the
case that we didn't
* isDir and dirExists had the same intention, but different
implementations for dmSUT. Replaced the dmSUT impl of getDirectory
with that of isDir's (which was much simpler). Removed
isDir from devicemanager.py, since it wasn't used externally
* killProcess modified to check for process existence before running
(since the actual internal kill command will throw an exception
if the process doesn't exist)
In addition to all this, more unit tests have been added to test these
changes for devicemanagerSUT.