8

To preface, I already checked this answer and unfortunately the bug was to do with CumulusCI which I am not using.

I have run into an obscure bug in SFDX Package Creation where a particular test is failing only on package version create, but building the package without --codecoverage works fine and then on deploying to a test scratch org, all tests pass. Unfortunately, a package without --codecoverage cannot be promoted.

The abridged version of the test is as follows:

/**
 * This test will attempt to update an existing draft. If a draft already exists on system while
 * a sync finds the same draft, it will delete all line items and recreate them to account for
 * possible deletion of line items in a draft.
 */
@IsTest static void testSyncUpdateExistingDraft() {
        Product2 pr = [SELECT Id FROM Product2 WHERE Name = 'test' LIMIT 1];
        PricebookEntry pbe = new PricebookEntry(Product2Id = pr.Id, UnitPrice = 500, IsActive = true,
                Pricebook2Id = Utils.getStdPricebookId(), Variant_ID__c = 'XXX');
        if (Utils.multiCurrencyEnabled) pbe.put('CurrencyIsoCode', 'USD');
        insert pbe;

        PricebookEntry uniquepricebookentry = [SELECT Id FROM PricebookEntry WHERE Variant_ID__c = 'XXX' LIMIT 1];
        Account a = [SELECT Id FROM Account LIMIT 1];
        Opportunity newOrder = new Opportunity(Name = 'test', AccountId = a.Id, CloseDate = System.today(), StageName = 'Draft Order', Order_Id__c='YYY', Pricebook2Id = Utils.getStdPricebookId());
        if (Utils.multiCurrencyEnabled) newOrder.put('CurrencyIsoCode', 'USD');
        insert newOrder;

        Opportunity newOrderReference = new Opportunity(Order_Id__c='YYY');
        OpportunityLineItem newOI = new OpportunityLineItem(Opportunity = newOrderReference, Product2Id = pr.Id,
                Unique_ID__c = 'ZZZ', Quantity = 7,UnitPrice= 10,PricebookEntryId=uniquepricebookentry.Id);
        insert newOI;

        List<OpportunityLineItem> oi = [SELECT Id, Quantity FROM OpportunityLineItem WHERE Unique_ID__c = 'ZZZ'];
        System.assertEquals(1, oi.size(), 'initial order item was not created');

        Utils.CustomHttpCalloutMock mock = new Utils.CustomHttpCalloutMock();
        mock.resp = getMockResponse();
        mock.respcode = 200;
        Test.setMock(HttpCalloutMock.class, mock);

        Test.startTest();
        QueueSyncDraftOrdersV2 q = new QueueSyncDraftOrdersV2(...);
        System.enqueueJob(q);
        Test.stopTest();

        oi = [SELECT Id, Quantity FROM OpportunityLineItem WHERE Unique_ID__c = 'YYY'];
        System.assertEquals(1, oi.size(), 'orderitem properties did not get created'); // line 113
    }

This test works fine in scratch orgs with multiple configurations (Person accounts on/off, multicurrency on/off). Unfortunately, I cannot see the debug logs of a package creation process so I don't know what is triggering the error. Weirdly enough, another test which creates a new draft passes the test, so I know it's not a problem with creating a new line item, it's just the process that deletes the old line item to create a new one that's not working, and ONLY during package creation.

Here is the output of sfdx force:package:version:create

Request in progress. Sleeping 30 seconds. Will wait a total of 570 more seconds before timing out. Current Status='Verifying metadata'
Request in progress. Sleeping 30 seconds. Will wait a total of 540 more seconds before timing out. Current Status='Verifying metadata'
Request in progress. Sleeping 30 seconds. Will wait a total of 510 more seconds before timing out. Current Status='Verifying metadata'
Request in progress. Sleeping 30 seconds. Will wait a total of 480 more seconds before timing out. Current Status='Verifying metadata'
ERROR running force:package:version:create:  Apex Test Failure: Class.TestQueueSyncDraftOrdersV2.testSyncUpdateExistingDraft: line 113, column 1 System.AssertException: Assertion Failed: orderitem properties did not get created: Expected: 1, Actual: 0

Things I tried:

  1. Removing --codecoverage, this works but I cannot promote the package.
  2. Putting --loglevel=TRACE with the hope that the debug log will output more data.
  3. Removing the test altogether, this works but then we're missing an important test.

While it might be difficult for someone to debug this from just seeing this test alone, I'm wondering if it's possible to see the debug logs of the package creation process.

6
  • It will be flat out impossible to help without seeing the specific way in which the test failed.
    – Adrian Larson
    Sep 14, 2020 at 16:12
  • 1
    @AdrianLarson fair point, I forgot to attach the most important part i.e. the output of the package creation
    – Rai
    Sep 14, 2020 at 16:15
  • 1
    @AdrianLarson May be the biggest question is, how can we debug a test that fails when creating a package but doesn't fail outside of this process?
    – jeromegv
    Sep 14, 2020 at 16:16
  • Did you ever get round this @Rai? I'm having a similar issue at the moment. Oct 28, 2020 at 9:03
  • Unfortunately not. @Daniel Ballinger's answer seemed the most promising (and that's why I acccepted it) because it seems logical to get the error log in this context. In my project I landed up backlogging the issue because I know the test is passing outside of this context.
    – Rai
    Oct 28, 2020 at 13:24

2 Answers 2

4

It might be a bit overkill, but...

Try deploying the package metadata to a blank dev org. And then have the dev org create the package via the older packaging methods.

You aren't so much interested in the resulting package (assuming it doesn't fail on the test). In this scenario the test cases will run in the context of the dev org and you can capture the resulting debug logs to help determine the failure reason.

3

In a version create command, the test is not run in your org. This means that there is absolutely no data or metadata available in the phantom org that runs the test except for that provided in the package.

You must create all the data you need for the test to pass. If you need to debug the logic, create a new Scratch Org, install your package and/or deploy your metadata there, and run the tests. You can use normal debug techniques at that point.

You may also want to look at Specify Unpackaged Metadata for Package Version Creation Tests (Pilot), although it's not clear that this would help you in this case.

2
  • Doesn't this essentially make the "SeeAllData" annotation useless for sfdx development? Oct 16, 2020 at 5:10
  • @captain_jim1 SeeAllData can still affect some tests (e.g. there are some library methods that require SeeAllData=true), but other types of tests that need SeeAllData=true won't be possible to run successfully or get high coverage with since there's no data and no way to fake that data. Fortunately, test coverage only requires an average of 75% over all classes, so this usually won't be an issue. I can't speculate on future plans, but I suspect that this will be addressed in a future release.
    – sfdcfox
    Oct 16, 2020 at 6:01

You must log in to answer this question.

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