(2013/11/14 9:18), Ted Mielczarek wrote:
On 11/13/13 3:34 PM, Mike Habicher wrote:
Hello everyone,
I'm working on automated tests for Gecko's camera code on B2G, and I
want to replace different pieces of the implementation with fake
objects that return one or more injected error codes so that I can
exercise all of the error-handling paths.
None of this code needs to be included in shipping B2G builds
(particularly if space on the target device is at a premium), so I was
wondering if there were a way to have it included in TBPL builds but
not otherwise.
I've spoken to a few people now and it doesn't sound like there is
such a thing, but it also sounds like it might be a useful thing to have.
Generally we test and ship the same bits, so this doesn't sound great.
That being said, having test-only prefs to enable this behavior seems
fine, I doubt that your test code is going to take up that much space.
There's some related work going on in a bug[1] on WebRTC testing that
you might find interesting.
-Ted
1. https://bugzilla.mozilla.org/show_bug.cgi?id=934667
We may need such error injection mechanism to test error handling paths
for TB (in relation to File I/O), too.
See bugzilla Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=936987
There are valid but hard to reproduce reliably bugs and testing against
them in automated test framework is almost impossible without such fake
error injection module/object/whatever.
Maybe a low-level I/O wrappers that simulate I/O errors, or
broken data read/write based on prefs
simulate_io_error with seed value (int) (non-zero).
If this value is non-zero, based on a psuedo-random number sequence
(initialized by prefs value), the routines would
behave erratically now and then. Such code indeed would not
add too much code space (less than 1KB for linux platform I suppose.)
and would expose bad error handling.
TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
