Benjamin Smedberg wrote:
[EMAIL PROTECTED] wrote:
I see an opportunity here to help the testing task. I am new to Mozilla
technologies but the XPCOM layer looks like a good place to stand and
reach down into other layers to test them.
XPCOM is a good way to define API interfaces and test them, but I don't
think this means that *standalone* XPCOM will be useful for testing.
You are right. XPCOM is a good way to define API interfaces and test
them. And it does not follow from that that a standalone XPCOM would be
useful. But I do believe a standalone XPCOM would be useful.
Most of our component have interdependencies in implementation; many
component require the networking stack to be available, for instance. Any
gecko component that is localizable ends up with a dependency on the chrome
registry, which has dependencies on the security system (CAPS).
Understood.
I think that we should test and treat "the toolkit" as a monolith, which
includes XPCOM, networking, etc. For some thoughts on this, see
http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/
Yes, I had read that post. I do not agree with it, but I do have enough
experience with Mozilla specifically to reply with the same authority.
Simply put, though, there is an answer to the combinatorial interfaces
and configurations problem. The answer is found in specified component
interfaces and automated testing. I do not expect you to believe me on
this, right now. But it is what I believe.
There needs to be tests of XPCOM standalone and XPCOM not standalone,
and this can work if they are automated and the tests test the specified
component interfaces.
- ray
_______________________________________________
dev-tech-xpcom mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
