[SalesForce] How to unit test service layer without DML

Looking for best practices/suggestions on how to unit test a service layer method that creates new records based on input without having to issue the DML.

An example would be OpportunitiesServiceImpl.createInvoices in fflib apex sample code. Given a list of opportunities, new Invoice__c & InvoiceLine__c records are created. The method could be tested by mocking UnitOfWork, but how to verify that the data on Invoice__c & InvoiceLine__c is correct. In other words, how to determine that invoice__c.InvoiceDate__c was set to opportunityRecord.CloseDate instead of opportunityRecord.SomeOtherDate?

The challenge with DML is that in more complicated situations then the one presented in createInvoices, related data might to exist in the DB which means it all needs to be setup, inserted, etc. Also, domain logic (onBefore/onAfter/etc) will fire when records are inserted and complicates situations and takes away from a true unit test.

Some ideas:

Stuck with DML – bad
Create a InMemoryDB and build a UOW that will add to InMemoryDB instead of calling insert/update/etc. – Possibly an enhancement to fflib common?
Have createInvoices return a wrapper class and inspect the wrapper class (e.g. InvoiceFactory concept with Invoices property). The challenge here is that you are validating the wrapper class not the Entity (SObject) and following this approach results in lots of wrapper classes when you have lots of service methods that do similar things in different areas of your app

Appreciate any thoughts/input, thank you!

Update – With some great insight from @andyinthecloud, the registerNew/registerDirty/etc. methods on the UOW itself can be verified to check the data resulted in the way expected. This avoids having to issue the DML. One note is to be aware of https://github.com/financialforcedev/fflib-apex-mocks/issues/8 which is what led me down the path of posting this since my attempts at this approach were not working as I expected. In summary, here's the approach:

// Create Mocks
fflib_ApexMocks mocks = new fflib_ApexMocks();
fflib_ISObjectUnitOfWork uowMock = new fflib_SObjectMocks.SObjectUnitOfWork(mocks);

// Set Mock
Application.UnitOfWork.setMock(uowMock);

// Call Service
MyService.doStuffThatWillInsertAccountRecord();

// create an account that should be the same as what
// registerNew was passed
Account expectedResult = new Account(Name = 'foo' .... );
((fflib_ISObjectUnitOfWork)
mocks.verify(uowMock, 1)).registerNew(expectedResult);
((fflib_ISObjectUnitOfWork)
mocks.verify(uowMock, 1)).commitWork();

Best Answer

There is a 'smoking hot' answer provided by @sfdcfox that exploits Json.deserialize to build in-memory relationships.

You can place your JSON strings in a library of static resources to mimic many use cases and cycle through those static resources in your test class/testmethods

Related Solutions

Testing service methods which fflib unit of work in method’s signature

Your first port of call should be this answer. See also this recent answer

Normally, one needs to inject the mock UnitOfWork into the fflib factories as such:

Application.UnitOfWork.setMock(mockUow);

But in your case, this isn't necessary as the code under test is passed the mockUow directly:

service.insertSerialNumbers(documentItems, assets, mockUow);

Your verify is trying to verify a list of sobjects using the matcher fflib_Match.sObjectsWith but your code under test calls registerNew in a loop.

Thus, you need this verify:

((fflib_SObjectUnitOfWork)mocks.verify(mockUow, mocks.times(1).description('Missed serial number insert')))
            .registerNew(fflib_Match.sObjectWith(  // singular
                    new Map<SObjectField, Object> {
                            AST_SerialNumber__c.AST_MaterialDocumentPosition__c => itemId,
                            AST_SerialNumber__c.Name => relatedAsset.SerialNumber,
                            AST_SerialNumber__c.AST_CreatorFlag__c => true
                    }
            
    ));

.. and again for each AST_SerialNumber__c your code under test creates

Summary

When verifying a call to the unitOfWork, you need to use the relevant matcher that corresponds to the code under test. If the call to the unitOfWork method has multiple arguments, you need to use matchers for each argument (for example, matching uow.registerRelationship)

Apex Mocks avoiding insert when committing fflib Unit of Work

There are three class private methods fired in this method. As they are private I'm not able to put them in class interface so I'm not able to mock them and verify - what is the right approach?

I would mock the public methods these private methods call (selectors, etc)
I would make the private methods @TestVisible and then test them directly with the public methods they rely on returning mocked results

Two of this private methods fired contain Unit Of Work as parameter. Look at example of insertSerialNumbers(documentItems, assets, uow) Is this right approach and how to unit test this private methods while I can't mock uow as it is not received from Application class in this private methods?

Basically same answer as above, mock the unit of work and call the private methods directly, passing in the mocked UoW

Test below fails with following exception ...

There can be lots of reasons for this including an improper mocking setup. Consult My ApexMocks Aren't Working, What Can be Wrong

And final question is: how to avoid result of uow.commitWork()?

You need to mock the UnitOfWork. The standard pattern for this is:

// Given mock Uow
fflib_SObjectUnitOfWork mockUow = (fflib_SObjectUnitOfWork) mocks.mock(fflib_SObjectUnitOfWork.class);
// Given mock UoW injected
Application.UnitOfWork.setMock(mockUow);

You are overthinking things by including an object that implements IDML. You should only need a custom object implementing IDML for Production code where the standard fflib DML order (inserts first, then updates, then deletes) needs to be different

Best Answer

Related Solutions

Testing service methods which fflib unit of work in method’s signature

Summary

Apex Mocks avoiding insert when committing fflib Unit of Work

Related Topic