4

I have developed a package which integrates two other pre-installed managed packages. The code coverage for my integration code is 96%.

When I build the package, certain objects/code from the pre-installed managed packages are included as dependent components. I want this dependency, because my integration package should only be installed in organizations which have the other two managed packages.

However, the upload fails because the code coverage drops down to 55% as a consequence of those dependent components.

Question 1: Why does the upload consider these dependent components when calculating code coverage? These components have already passed the code coverage threshold, otherwise they wouldn't be part of a managed package.

Question 2: How do I write unit tests that cover code in a (foreign) managed package?

Improve this question
3
  • 1
    This does sound odd, forgive me for asking, but are you sure you have included all your tests in the package?
    – Andrew Fawcett
    Commented Nov 3, 2013 at 10:03
  • The integration package consists of TWO VisualForce pages and their controllers. These pages override pages in one of the packages (owned by us) and re-directs to a page on the other package (not owned by us). Very simple.
    – phil vasey
    Commented Nov 4, 2013 at 6:29
  • There is a single test class that covers 96% of the code in the TWO controllers.
    – phil vasey
    Commented Nov 4, 2013 at 6:30

2 Answers 2

Reset to default
2

It seems the code coverage estimator gives the incorrect value of 96%, rather than the upload which reported the correct value of 55%.

Extending the unit tests has resolved my issue. Thanks.

Improve this answer
1
1

You can't really write tests to cover foreign code as you don't necessarily know what's in thee.

It sounds as though you're relying on the other packages to perform various operations (via triggers or something) to update data during your tests and I think you'll find those components won't actually be added to your package in reality as I don't think there's a mechanism that will allow them to belong to more than one namespace.

If that's the case then you're going to have to modify your tests to do some of the hard work themselves; you could do this through simply updating fields as they would be. Another (nasty) way might be to just take chunks of the code from the other packages and embed them in your tests.

Sounds like we need a good mechanism for specifying dependencies!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .