I'm sorry, I don't seem to understand what you're saying. You seem to be
saying: "JS files that implement XPCOM interfaces [which you can't test]
without exposing them via an interface". Which prompts me to ask:
Does the code, without taking testing into account, need to implement an
interface (e.g. nsIObserver or nsIWebProgressListener or whatever) ?
If so, use an xpcshell test, createInstance/getService your
JS-implemented instance, and then wrappedJSObject your way to victory
(more details in Philipp's reply and at
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Building_components_in_JavaScript#Using_Your_Component
.
If not, don't make it implement an interface, but use a JS module
instead, and then using:
let backstagePass = Cu.import("resource://gre/my/jsm");
you can access the internals. Benjamin's suggestion of loading the
component (even in the case where it is an XPCOM component) as plain JS
using Cu.import is probably worth exploring, too...
~ Gijs
On 07/07/2014 18:53, Josh Matthews wrote:
Garvan is referring to JS files that implement XPCOM interfaces. It's
impossible to test internal details of the components without exposing
them via an interface, which can end up convoluting the code in some cases.
Cheers,
Josh
On 07/07/2014 12:32 PM, Gijs Kruitbosch wrote:
On 07/07/2014 17:25, gkee...@mozilla.com wrote:
We have no unit test framework for internal JS, does anyone have any
interesting ideas on how to accomplish this with our existing testing
frameworks?
Should I just leave unit testing functions in the JS file, so they can
be run manually during future development?
I'm not sure what you mean by "internal" JS. We have xpcshell tests, in
which you could load an arbitrary JS file if you wanted, and then run
tests against the functions in that file. Or if it's a JSM, you could
load that and use the result of Cu.import to do internal tests (as that
will produce a BackstagePass which will allow you to interact with
non-exported symbols from that JSM).
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
