Comments (16)
@afawcett Since our last post I have been able to put both what I refer to as "Apex Enterprise Patterns" (AEP), and ApexMocks into their own artifacts within my org's code repository like so:
As you can see as long as I define each package (or "artifact") within the sfdx-project.json like so then when I push to a scratch org or convert using the force:source:convert then it will compile the metadata accordingly and put it in the org properly (bar any name collisions, hence I keep the prefixes as they are).
Note: You can see that in this way I can separate the default files from the test without an issue, and I can maintain AEP and ApexMocks separately as you have or collectively if desired. When I put this in a new org I get 93% code coverage out of the box
As you can see from the first screenshot, I intend to separate regional development (US, UK, AU, etc.) in separate artifacts (possibly package 2.0 packages) that will depend on everything within core which includes FFLib. Hope that update helps some!
from fflib-apex-common.
Can you elaborate more on what you mean by 'manually update every place an account, contact and activity are used rather than update a test data class' ? Is this because you have validation rules in your org on these objects that cause the tests to fail? If so, yes i get it, a single Test Data Class would be a good idea.
from fflib-apex-common.
@tmowbrey For creating records, I've had great success using @dhoechst TestFactory
from fflib-apex-common.
@afawcett As an example, in fflib_SObjectSelectorTest, there are multiple methods using the same account data setup information. When I install it in one org (or update), I have to add BillingCountry to each method, copy+pasting each time. In another org I have to add BillingState and Billing Country. While not a large issue, the copy+paste leads me to believe that this information should be consolidated into a separate class for data generation to make updating test data easier when required. I think adding in functionality similar to the package @daniel-huckins has mentioned would help enforce some best practices when using the library as well as help increase the usability of the library.
Thoughts?
from fflib-apex-common.
Yeah got it, sounds good, though i think there are plenty of good libraries doing this, in this case, for better internally management of test data can we just factor into a single test data setup class perhaps, that would address your need and not add to much more bloat to the library (i'm hoping to get round to review thoughts elsewhere in this repo to modularising this at somepoint).
from fflib-apex-common.
I am currently arguing with myself the pro and cons of:
-
Use the library "as-is", making it easy to maintain but leaving questions about long term implementation and extending functionality. I'll refer to this option as "Fostering"
-
Removing the
fflib_
prefix and making the library our own. Allowing us to customize without some fancy extending of the classes, and also providing clarity in our repository (when using 3rd party library I'd like to refer to it as 3rd party package and not manage it in our codebase). I'll refer to this option as "Adopting"
This issue is actually one of the conflicts that has me feeling more confident about option 2 in the long run. We have validation rules that cause the DML operations in the test to fail, so I can't see around modifying the test directly use my Forge.cls
which handles the org's validations rules when creating an object instance.
I guess in your opinion when is it valid to "Adopt" the library and maintain it manually verses "Fostering" it as a 3rd party library within our codebase?
from fflib-apex-common.
@Xtremefaith i totally misunderstood your original question here. I now understand your issue about different org shapes and validations impacting the tests for the library.
I think the best way to approach this is to use more mocking and/or making the tests more agnostic if possible. Can you get the ball rolling with like a top 3 most common test failures and why?
We can then come up with some ways to either avoid making changes (better more org agnostic tests) or at the very least make your code edits easier via some more centralised approach in the lib.
Hows this sound?
from fflib-apex-common.
@afawcett Sounds great! So one of my first issues was just getting fflib into my environment. For example fflib_QueryFactoryTest.cls
has multiple instances of inserting a new task. Because my org has a validation rule that requires a certain prefix on the Subject
I now need to add a value to the Subject
field prior to INSERT
. At the moment I have resolved this by creating each object through my Forge
class like so:
Task tsk = (Task) Forge.createSObject('Task');
This class then accounts for all org related validation rules. But the fact that I've now edited code from an external library/repository feels dirty. I feel I either should adopt this codebase as my own and possibly drop the fflib_
prefix or I should just reference this from a managed package where perhaps FFLIB
is the namespace.
At the moment I believe this is the only real conflict, as you mentioned I stub everything else through mocking. I still haven't established our domain model yet as I've just been working through the learning curve of these patterns (studying PEAA from Martin Fowler), ApexMocks, and the best approach to implementing this code base and its future with our own code base and its future.
Update:
Another instance that causes grief is in the ApexMocks fflib_MatcherDefinitionsTest.cls, at line 52 it attempts to insert an SObject
that is an Account
and again we have validation rules that prevent certain characters in the account name because of an integration to QuickBooks (sorry I voted for FinancialForce :P ). So we get the following error:
System.DmlException: Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Account name cannot contain a ":". A colon is a special system symbol used by Quickbooks.: [Name]
Class.fflib_MatcherDefinitionsTest: line 52, column 1
Hope that helps!
from fflib-apex-common.
Yep this helps, the requirement seems clear now. Some kind of abstraction or perhaps a test plugin means to customize the way standard objects are initialized in tests. So if there was say fflib_ITestHelper interface and the tests looked for a class called say FFLibTestHelper that implemented the interface. The interface would have methods like createTask. The framework could include base impl of the interface you could extend and override. Would something like this work?
NOTE: If you put fflib in a managed package, you will need to make all the classes global and the prefix will be fflib.fflib_SObjectDomain (for example). Also you will inhibit upgrades to the library, since global has constraints that are not neccessarly constraints when evolving the library.
from fflib-apex-common.
I think this will work, not sure I completely understand what you have in mind but yes the ability to extend/customize the way objects are initialized in tests would be great!
Meanwhile I'm in the Salesforce DX pilot and attempting to package fflib in its own "app" to see if this is a more viable means of "packaging" it within our org's codebase. I think this will work in the long run just not 100% sure how it will all work together just yet but I'll keep you posted.
from fflib-apex-common.
Excellent, thanks @Xtremefaith for the update. Yes we are also in the SFDX pilot and very keen to explore how libraries can be used in it. Keep us posted on your findings! 👍
from fflib-apex-common.
@afawcett if you have a chance I posted some findings in the DX chatter group, one specifically on ApexEnterprisePatterns as a separate workspace, but unfortunately when it gets to dependencies questions within DX the forum seems to go stale. I currently have it setup as a workspace, with an AEP
project, and ApexMocks
and fflib
as apps within the project. like so:
- /ApexEnterprisePatterns/AEP/ApexMocks/default/
- /ApexEnterprisePatterns/AEP/FFlib/default/
Again though no confirmation from anyone on their end to determine if this is inline with DX and more importantly Packaging 2.0 when it comes to deployment. I also started a #dx channel on the Salesforce Community Slack Team as a means to chat about some opinions surround DX build outs and deployment strategy.
As of right now I feel really prepared to use this patterns but I'm struggling to force it into a segmented DX structure as I feel it should.
from fflib-apex-common.
@Xtremefaith i need to check my access on the chatter group, as the link is not working for me. How is the discussion going since your last post above?
from fflib-apex-common.
This is very cool! @phardakerffdc FYI
from fflib-apex-common.
Has there any developments with this issue? I just came across the issue again in another org where a a specific field was set to required required on Task/Events and now I have 9 fflib_
test failing. So naturally I'm again questioning the best practice for now.
from fflib-apex-common.
I'll admit that I didn't read this whole thread but the gist is that integration tests fail in some orgs due to validation rules or other constraints applied to Standard Objects. We made improvements in prior years to mock away some raw DML in various test methods/classes and that has improved things .. but there will always be gaps. We can't mock away the database in every test case since this library is basically all about interfacing with the database
from fflib-apex-common.
Related Issues (20)
- Unable to Deploy - Unhandled Exception : java.lang.RuntimeException HOT 1
- Unit test failure in multi-currency org HOT 4
- Deploy button doesn't deploy because there are test failures HOT 1
- Expected a QueryException due to read only user not having access to Opportunity HOT 7
- Switch to Inherited Sharing on SObjectDescribe and SObjectSelector HOT 2
- With latest fflib, do TriggerHandlers become service class consumers? If so what happens to UoW? HOT 6
- Selected tests in fflib_SObjectSelectorTest fail in an org with encryption enabled on Account.Name HOT 2
- Selector Mocks to Include SOQL Query Retrieve Check HOT 1
- fflib_SObjectUnitOfWork doCommitWork executes all dml for all registered types even if there are no changes
- Update README as session recordings are not available HOT 2
- fflib_SObjectDescribe.cls fails to resolve cross-object field paths for Person Accounts
- Aggregate SOQL support. HOT 2
- Disable Savepoint in tests HOT 4
- Inconsistent Code Coverage and Test Failures in fflib-apex-common HOT 1
- fflib_SObjectSelector and fflib_SObjectUnitOfWork have insufficient test code coverage. HOT 2
- Add queryWithBinds to Selector layer HOT 2
- Unit test failing fflib_SecurityUtilsTest & sysadmin_objectAndField_access HOT 8
- Coverage of UnitOfWork class HOT 1
- Versioning HOT 1
- fflib_SObjectSelectorTest failure with Lookup relationship and Person Type Accounts HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fflib-apex-common.