Open scottpelak opened 5 years ago
I like your insight into the FFLIB. The parts of our general readme don't address fflib in detail yet. I'm hoping someone much more skilled/versed in that regard can take it up if they have time before I do. Another thing: for both the explanation of how to use FFLIB and the caveats that you mention, I think it could be beneficial to break those apart into separate documents so that the main readme isn't too large to consume. We want developers to have a relatively manageable list of things to be aware of and if they need/want more information with the more complicated and nuanced recommendations we can refer them to something like this.
What do you think?
I agree. Maybe have a library of README
s talking about different topics.
We could also develop a repo of Utility classes to implement the best practices (perhaps here? or in a public repo? Or a repo that's MIL-specific?).
System.debug(...)
statementsType getType()
, store Job's Type's Name in Metadata, then call Type nextJobType = Type.forName(metadata.Next_Job__c);
and check Type's instance is implements the correct interface/abstract class, etc.I would absolutely love to have a section dedicated to shared code. I'm not aware of the org structure in all of our Salesforce solutions or if we use only one org, but as or if we move to new orgs then having utility classes that can be used regardless of org can be a tremendous help. For example, something like a recordType utility helper.
I say go for it if you have extra time.
Maybe MIL Corp should create a Managed Package that contains common Utilities/best-practices. Then as they service more Customers/Orgs, they can install the Managed Package instead of copying-and-pasting the code.
Plus, Apex in Managed Packages doesn't count towards Apex Character Limit (though it doesn't seem like limits are generally a concern for government Orgs...)
fflib_ApexMock has a potential bug:
static String extractTypeName(Object mockInstance)
only works iftoString()
isn't overriddenAn alternative is have an interface/abstract method on
fflib_ApexMocks
to return the Type of the implementation:Type getType()
which can streamline stub creation.What's even more fun is non-test classes can have an inline/hard-coded Type of a
@IsTest
class .Below is a quick-draft sample Stubbing framework. One still has to manually code when to use the stub during a test. Even further below is a sample Mocking framework for APIs which doesn't require to manually use the Mock during a Test -- the API always sets the Mock when
Test.isRunningTest()
is true.Stubbing Framework
Mocking Framework
Below uses a helper class:
Debuggable
. See https://github.com/flexchecks/debugger