Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

calling TestDataSupplement #33

Open
dmchaplin opened this issue Mar 18, 2020 · 3 comments
Open

calling TestDataSupplement #33

dmchaplin opened this issue Mar 18, 2020 · 3 comments
Assignees

Comments

@dmchaplin
Copy link

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

@goto-dev-null
Copy link

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
Copy link
Collaborator

stohn777 commented Aug 3, 2021

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
Copy link
Collaborator

stohn777 commented Aug 4, 2021

@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.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants