Book Image

Mastering Application Development with

By : Kevin J. Poorman
Book Image

Mastering Application Development with

By: Kevin J. Poorman

Overview of this book is an extremely powerful, scalable, and secure cloud platform, delivering a complete technology stack, ranging from databases and security to workflow and the user interface. With's cloud platform, you can build any business application and run it on your servers. The book will help you enhance your skillset and develop complex applications using It gets you started with a quick refresher of's development tools and methodologies, and moves to an in-depth discussion of triggers, bulkification, DML order of operations, and trigger frameworks. Next, you will learn to use batchable and schedulable interfaces to process massive amounts of information asynchronously. You will also be introduced to Salesforce Lightning and cover components—including backend (apex) controllers, frontend (JavaScript) controllers, events, and attributes—in detail. Moving on, the book will focus on testing various apex components: what to test, when to write the tests, and—most importantly—how to test. Next, you will develop a changeset and use it to migrate your code from one org to another, and learn what other tools are out there for deploying metadata. You will also use command-line tools to authenticate and access the Rest sObject API and the Bulk sObject API; additionally, you will write a custom Rest endpoint, and learn how to structure a project so that multiple developers can work independently of each other without causing metadata conflicts. Finally, you will take an in-depth look at the overarching best practices for architecture (structure) and engineering (code) applications on the platform.
Table of Contents (16 chapters)
Mastering Application Development with
About the Author
About the Reviewers

Structuring unit tests

In general, there is only one overarching pattern for unit testing code on the Salesforce1 platform. The essential differences between the Salesforce1 platform and other software development stacks does make unit testing is a bit different. That said, if you're familiar with unit testing in other languages, this will largely seem familiar to you. Here's the general pattern:

Using your own data

Each of our test methods needs to create its own test data. While this seems cumbersome and time consuming, it's the only safe way to run unit tests. Relying on existing data in your org is problematic because you cannot ensure that the data will exist in your other orgs. Assuming an account will exist in your production org just because it exists in your development sandbox is a great recipe for frustrating deployments. This often finds its way into our tests through the use of hardcoded IDs. Querying for an account where the ID is X, for instance, not only assumes that the account...