Hi @dmchaplin.

Thank you for your interest in and contributing to the AT4DX library.

The TestDataSupplementer is an anti-pattern to proper, preferred, mock-based testing, although many codebases have legacy, DML-based unit tests that can be undermined by changes to record-validity logic, e.g. modifying a SObject to have a required field which was previously optional. Any DML-based test that didn't address the field in the past, will be broken at this point. The test-data supplementation scheme addresses this problem without having to potentially embark on an inconvenient, extensive effort of replacing all broken logic with mock testing. It's a convenient workaround for the time when legacy patterns have yet to be transitioned.

With the sole purpose of this pattern being temporary and testing based, including it in the ApplicationSObjectDomain class violates separation of concerns principles.

The supplementer supports two SOLID architecture principles:

• Encapsulation of the record-validation logic in the proper scope. Account record-validation logic can be contained in the same scope as the Account yet accessible to dependent scopes needing it.
• Dependency-injection-based logic for extending related logic. Once implemented in a dependent scope, extensions to the record-validation rules will automatically be picked up.

The AT4DX sample code repo [1] has examples of the intended usage of the pattern. Note the two files.

• sfdx-source/reference-implementation-marketing/main/classes/supplementers/MarketingFieldsForAccountsSupplementer.class
• sfdx-source/reference-implementation-marketing/test/classes/AccountSupplementationTest.class

MarketingFieldsForAccountsSupplementer would exist within the same scope as the Account SObject, and AccountSupplementationTest exemplifies the unit-test usage of the TestSupplementer to further populate an Account with record-validation-related data.

[1] https://github.com/ImJohnMDaniel/at4dx-samplecode

@stohn777

Thanks for the well-thought-out response. Learning AT4DX has been very rewarding.

I've never liked using .isRunningTest() in code, but SOC is a good justification for why that is the case.

It makes sense that MarketingFieldsForAccountsSupplementer would exist in the same scope as the Account Sobject. How does the legacy code know to call supplement()? Is it a one-time edit to each of those test classes to add it?

Thanks, shiny side up and tailwinds.
Drew

@dmchaplin

You're correct that the unit tests would need the one-time addition of the TestSupplementer logic, as conceptualized in the AccountSupplementationTest.cls.

"shiny side up and tailwinds" Are you a fan of aviation? 💯

Best wishes.

@stohn777

Yes, I own a '67 Skyhawk and have somewhere around 600 hours. Somewhere along the line, I spotted your linked-in profile and thought I'd give you a shout-out.

@dmchaplin
I got it. Never mind. :-)

@dmchaplin This change was incorporated into the recent "improved test coverage" work. Thank you for the great catch and solution on this. GG

1341480