I think providing a non-public API to modify the run-time behavior of
code, using gtest's FRIEND_TEST macro to give tests the ability to
modify private class members, or using Google's "googlemock" C++ mocking
framework are all better than littering #ifdefs like this throughout the
code.
Furthermore, #ifdefs like you suggest would require multiple compiler
invocations. For every platform, we compile once and ship that. Your
suggestion would seemingly require us to compile twice. We don't have
the infrastructure capacity to do this. I don't think the financial
expense could be justified given the much cheaper alternatives.
On 11/13/13, 12: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.
Example usage:
#ifdef TEST_MODE*
if (mozilla::Preferences::GetBool("camera.test.mode", false)) {
return FakeCameraInstance();
} else {
#endif
return RealCameraInstance();
#ifdef TEST_MODE*
}
#endif
Thoughts?
--Mike.
-----
* bikeshed away. :)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
