calling TestDataSupplement

[dmchaplin]

Does the TestDataSupplementer.supplement method need to be called explicitly in each test method? I don't see where it is called anywhere in the framework.

So using the at4dx-sample example. Where does the upstream package call the TestDataSupplementer.supplement so that the MarketingFieldsForAccountsSupplementer can insert the "Hellow World!" slogan.

My exact issue is that we have a required field on Product2 and now the fflib tests are failing: fflib_SObjectUnitOfWorkTest.testDerivedUnitOfWork_CommitSuccess Fail System.DmlException: Insert failed. First exception on row 0; first error: REQUIRED_FIELD_MISSING, Required fields are missing: [Part_Number__c]: [Part_Number__c] 122

[jonnypetraglia]

I believe the answer to your question is "Yes", you have to call it for every test, but I'd personally have a test data factory that is what calls the Supplementer. Either per-object or even a generic one for any SObjects. At the very least, put them in the @testSetup method.

[stohn777]

Hi @dmchaplin

The intent of the test-supplementation feature [1] is enabling sub-packages to define additional behavior for SObjects that are controlled by super-packages. Account is a very basic SObject that would be controlled by a package that's very low in the package hierarchy tree, however packages further up the tree will likely want to add or change Account's behavior. Consider the following.

• Package A controls the Account object
• Package B adds a field requirement to Account, host the test-supplementation logic for the requirement, and supplies a CMD record defining the test-data-supplementation injection
• Package A implements the test-supplementation logic which "supplements" its Account test data to accommodate the added requirement

Highly forward-looking architects may specify test-supplmentation usage early in the application's design thereby automatically picking-up support for additional requirements. However more reactive architects, following YAGNI, might add the test-supplementation usage only when needed by the sub-packages.

I agree with @jonnypetraglia that one's test-data factory would be a great place for more centralized usage of the test-supplementation feature.

Thanks.

[1] https://github.com/apex-enterprise-patterns/at4dx/wiki/Test-Data-Builder-Field-Injection

[stohn777]

@dmchaplin and others

Just to clarify the meaning of sub- and super-packages. I sometimes attempt to correlate the concept of super- and sub-classes. A super-package is one being lower on a hierarchy tree and contains functionality that a sub-package would use. In other words, a sub-package is dependent on the super-package, and a super-package may have more than one sub-package.

Considering the package hierarchy below, Package A is the penultimate super-package and packages B and C are sub-packages of A, while Package B is the super-package to Package D.

I hope that better explains the terminology for those who may have not understood my analogy.