- Force.com Enterprise Architecture - Second Edition
- Table of Contents
- Force.com Enterprise Architecture - Second Edition
- Credits
- Foreword
- About the Author
- Acknowledgements
- About the Reviewers
- www.PacktPub.com
- Customer Feedback
- Preface
- 1. Building, Publishing, and Supporting Your Application
- Required organizations
- Introducing the book's sample application
- Package types and benefits
- Creating your first managed package
- Package dependencies and uploading
- Becoming a Salesforce partner and benefits
- Introduction to AppExchange and listings
- Installing and testing your package
- Licensing
- Providing support
- Customer metrics
- Trialforce and Test Drive
- Summary
- 2. Leveraging Platform Features
- Packaging and upgradable components
- Understanding the custom field features
- Understanding the available security features
- Platform APIs
- Localization and translation
- Building customizable user interfaces
- E-mail customization with e-mail templates
- Process Builder, Workflow and Flow
- Social features and mobile
- Summary
- 3. Application Storage
- Mapping out end user storage requirements
- Understanding the different storage types
- Reusing the existing Standard Objects
- Importing and exporting data
- Options for replicating and archiving data
- External data sources
- Summary
- 4. Apex Execution and Separation of Concerns
- 5. Application Service Layer
- 6. Application Domain Layer
- Introducing the Domain layer pattern
- Implementation design guidelines
- Domain class template
- Implementing Domain Trigger logic
- Implementing custom Domain logic
- Object-oriented programming
- Creating a compliance application framework
- An Apex interface example
- Testing the Domain layer
- Calling the Domain layer
- Updating the FormulaForce package
- Summary
- 7. Application Selector Layer
- 8. User Interface
- Which devices should you target?
- Introducing Salesforce Standard UIs and Lightning
- Leveraging the Salesforce standard UIs
- Generating downloadable content
- Generating printable content
- Client server communication
- Managing limits
- Object and field-level security
- Managing performance and response times
- Using the Service layer and database access
- Considerations for using JavaScript libraries
- Custom Publisher Actions
- Creating websites and communities
- Mobile application strategy
- Custom reporting and the Analytics API
- Updating the FormulaForce package
- Summary
- 9. Lightning
- Building a basic Lightning user interface
- Lightning architecture
- FormulaForce Lightning Components
- Making components customizable
- Integrating with Lightning Experience
- Lightning Out and Visualforce
- Integrating with communities
- Testing
- Updating the FormulaForce package
- Summary
- 10. Providing Integration and Extensibility
- Reviewing your integration and extensibility needs
- Force.com platform APIs for integration
- Application integration APIs
- Exposing Lightning Components
- Extending Process Builder and Visualflow
- Alignment with Force.com extensibility features
- Extending the application logic with Apex interfaces
- Summary
- 11. Asynchronous Processing and Big Data Volumes
- 12. Unit Testing
- 13. Source Control and Continuous Integration
- Development workflow and infrastructure
- Developing with Source Control
- Hooking up Continuous Integration
- Releasing from Source Control
- Automated regression testing
- Summary
- Index
It is tempting to allow the testing of the Service layer to be done via tests around the calling code, such as Visualforce controller tests. However, depending solely on this type of testing leaves the Service layer logic open to other use cases that may not strictly be covered by the controller logic. For example, a custom controller using StandardController will only pass in a single record and not multiple ones. Make sure to develop specific Apex tests against the Service layer as the functionality is developed.
Sometimes, the data setup requirements of the Service layer are such that it makes writing Apex tests for controllers or other callers, such as Batch Apex, quite complex and thus expensive, not only in terms of server time for the test to run (due to data setup for each test method) but also in terms of developer time, while preparing a full set of test data.
While you still need to test the full stack of your code, there is an approach called mocking, which can be used in conjunction with the previously mentioned factory pattern, which will allow the test context for the given service caller to implement its own test implementation of the service that mimics (with hardcoded test responses) different behaviors that the controller is expecting from the service method. This allows the controller tests to be more varied and focused when devising tests. Again, this mocking approach has to be used in combination with full stack tests that truly execute all the code required. Chapter 12, Apex Mocks, will cover mocking the Service layer in more detail.
-
No Comment