What about wrappedJSObject? If the test is geared towards internal
details of the implementation anyway, it should be possible to do
something like this:
xpcom component:
function MyXPCOMComponent() {
this.wrappedJSObject = this;
}
MyXPCOMComponent.prototype = {
_internalMethod: function(a,b) { ... }
};
unit test:
function run_test() {
let comp = Components.classes["@foo/bar;1"].createInstance();
let jscomp = comp.wrappedJSObject;
// now do things with jscomp
do_check_eq(jscomp._internalMethod(20, 30), "yup");
}
On 7/7/14 7:53 PM, 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
