On Wednesday I figured out how to get a standalone mochitest to write the output to a log file. This was required since in Windows Mobile builds of Fennec we could not get the iframe to load a source file with all the magic mochitest bits. That is something we need to fix, but for getting tests running (on Windows Mobile) all roads were pointing towards running each test file by itself while using a remote web server instead of localhost. Now I can just launch fennec on my phone and run a test:
\tests\fennec\fennec.exe --environ:NO_EM_RESTART=1 -no-remote -profile \tests\mochitest\mochitesttestingprofile\ http://192.168.55.100:8888/tests/content/canvas/test/test_2d.composite.canvas.source-over.html?logFile=%5ctests%5cmochitest%5c314.log
I let a python script run all night long and came back with 113 tests ran. Seems the device locked up on me again. So all day Thursday I kept working on it and finding hang after hang. I decided that running python on the device might not be the best approach due to the extra memory usage. I worked for a few hours on blassey‘s remote test harness, but could not get it to detect when the process exited (really had 2 zombie threads). I found some xda tools (prun, pget, pdel) which allow me to launch my fennec command line from my tethered host machine. What I do here:
prun -w \tests\fennec\fennec.exe ...
pget [logfile] [locallog]
Now I am not worried about space on the device with the tests or the log files.
Here is what we need to make this a solid package and running on tinderbox:
- Sort out python script to generate mochitesttestingprofile and get it on the device
- Fix profile and tests to remove localhost/127.0.0.1 dependencies
- Fix tests to remove calls to local files (an example I found)
- Test on a release build of Fennec with desktop tests.tar
- Verify tools like certutil.exe, ssltunnel.exe, etc.. do not cause any problems
- Write tools in the python script to look for a test that doesn’t exit and clean up zombie processes