31,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Design and develop state-of-the-art applications using Force.com's powerful development platform
About This Book
- Flaunt your skillsets by developing complex applications that include demanding concepts such as triggers, Visualforce controllers, batch jobs, and Lightning components
- Earn the gratitude of your colleagues by structuring a project so that multiple developers can work independently of each other
- Kevin Poorman, the author of the book and a Force.com MVP, shares his years of Force.com knowledge and experience with you through the medium of telling examples
Who This Book Is For
If you're a Force.com developer with a fundamental understanding of Apex and JavaScript but now want to enhance your skills with tips, tricks, and guidance on the best architectural and engineering practices, then this book is for you.
What You Will Learn
- Creating triggers, and the best practices for writing them
- Developing a number of Visualforce controllers and extensions
- Integrating third-party web APIs into your Apex code
- Writing unit tests that cover testing bulk safety, user and profile settings, and negative tests
- Creating a Lightning component for use in Salesforce1
- Getting acquainted with various methods for deploying metadata between orgs
- Using the Rest sObject API for access to Salesforce objects and data using the REST methodology
- Learning about overarching architectural considerations such as naming conventions, testing practices, and data modeling practices
In Detail
Force.com 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 salesforce.com's Force.com 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 Force.com. It gets you started with a quick refresher of Force.com'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 Force.com 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 Force.com platform.
Style and approach
A step-by-step tutorial, with plenty of tips and tricks that will help you develop complex Force.com applications.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 321
Veröffentlichungsjahr: 2016
Ähnliche
Mastering Application Development with Force.com
Mastering Application Development with Force.com
Copyright © 2016 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: January 2016
Production reference: 1200116
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78217-281-9
www.packtpub.com
Credits
Author
Kevin J. Poorman
Reviewers
Rakesh Gupta
Zarna Chintan Naik
Rahul Sharma
Gautam Singh
Commissioning Editor
Rebecca Youe
Acquisition Editor
Sonali Vernekar
Content Development Editor
Shweta Pant
Technical Editor
Pranjali Mistry
Copy Editor
Pranjali Chury
Project Coordinator
Shipra Chawhan
Proofreader
Safis Editing
Indexer
Mariammal Chettiyar
Production Coordinator
Nilesh Mohite
Cover Work
Nilesh Mohite
About the Author
Kevin J. Poorman has been working with the Salesforce1 platform since 2008. He has architected and built a number of applications on the platform for enterprises and fortune 500 companies in the advertising industry. He has been a Force.com MVP for 3 years. He is active in the community as a developer user group leader, and he can also regularly be found blogging at http://www.codefriar.com, on Twitter (@codefriar), and on the #salesforce IRC channel as well as on the Salesforce developer forums and Salesforce stack overflow. He has also created and maintains the ngForce library for writing Angular.js apps on the platform. In 2015, Kevin joined the Salesforce Marketing Cloud as a senior customer success architect helping marketers succeed at mobile marketing. He regularly speaks on mobile development using Salesforce1, the Salesforce Marketing Cloud, Ionic, and RubyMotion.
I'd like to take some time to thank those who helped this book become reality. First and foremost, my wife, Stephanie, who's been instrumental in encouraging me when I got anchored in the morass of writer's block. Also, I'd like to thank Reid Carlberg and Jeff Finken, who have always been more my mentors than bosses. And, I couldn't have done any of this without the support and friendship of the Salesforce MVP community. I am truly blessed to have been able to write this while standing on the shoulders of not just giants, but Titans who have never feared reaching out to help others. Thank you all.
About the Reviewers
Rakesh Gupta is a Salesforce MVP, evangelist, trainer, blogger, and an independent Salesforce consultant. He is from Katihar, Bihar, and he lives in Mumbai. He has been working on the Force.com platform since 2011. Currently, he is working as a Salesforce consultant and is a regular contributor to the Salesforce Success Community. He is the coauthor of Developing Applications with Salesforce Chatter and Salesforce.com Customization Handbook, Packt Publishing, and he is also a technical reviewer of Learning Force.com Application Development, Packt Publishing. He is the author of Learning Salesforce Visual Workflow, Packt Publishing. He has written more than 150 articles on Flow and Process Builder to demonstrate its use to minimize the code usage. He is one of the flow experts from the industry. He is very passionate about Force.com and shares information through various channels, including his blog at http://automationchampion.com.
He has trained more than 200 professionals around the globe and handled corporate trainings. He has six certifications in Salesforce. He works on all the aspects of Salesforce and is an expert in data migration, integration, configuration, and customization. He is the leader of the Navi Mumbai and Nashik developer user groups in India. He is also the initiator of the Mumbai Salesforce user group. He organizes meetups at regular intervals for the groups he is part of.
He can be reached at <[email protected]>, or you can follow him on Twitter at @rakeshistom.
I would like to thank my parents, Kedar Nath Gupta and Madhuri Gupta, my sister, Sarika Gupta, and my friend Meenakshi Kalra for helping me make time for writing blogs and encouraging me. Also, I would like to thank the team at Packt Publishing and the author of this book for giving me this unique opportunity.
Zarna Chintan Naik is a proprietor of YES CRM Consultants, a Salesforce.com consulting company based in Mumbai. YES CRM Consultants is primarily focused on Salesforce.com consulting, administration, and training services for clients based around the globe.
Zarna and her team also have expertise in multiple appexchange products, including Conga Merge, Clicktools, Rollup Helper, and Drawloop.
Zarna herself holds multiple certifications: Salesforce.com Certified Administrator, Developer, and Sales and Service Cloud Consultant. Previously, she worked for one of the leading Salesforce.com partners in the USA. She has also reviewed Learning Force.com Application Development, Packt Publishing. To know more about Zarna and YES CRM Consultants, log on to www.yescrm.org or visit her LinkedIn profile at https://in.linkedin.com/in/zarnadesai.
I would like to thank my parents, in-laws, husband, sister, friends, and family for their continued support for my work.
Rahul Sharma has been working on the Force.com platform since 2010 and is a certified advanced developer and administrator. He has worked on many applications involving custom development and integration. He is an active super contributor to the Force.com community and Stackexchange. He holds a bachelor's degree in electronic engineering and is based out of Mumbai, India. His areas of interest are JavaScript and mobile development other than Salesforce. He can be reached at about.me/rahuls91221.
Some of the other books he has worked on are Learning Force.com Application Development and Visualforce Developer's Guide, both by Packt Publishing.
Gautam Singh is a computer science engineer, blogger, online trainer, technical reviewer, and a smiling human being. He is from Patna, Bihar, and he lives in San Jose, California, USA.
He has been working with the Salesforce platform since 2012, and from the very start he has contributed to motivating and training a large number of homo sapiens in Salesforce and its certificates. Recently, he was on the reviewer panel for Learning Force.com Fundamental, Packt Publishing.
Currently, he works for Jade Global Inc. as a techno functional consultant. He holds numerous Salesforce certifications, such as Certified Developer [DEV-401], Certified Developer [ADM-201], Certified Advanced Developer [ADM-211], and Sales Cloud Consultant. He is now on course to complete the Salesforce Certified Advanced Developer [DEV-501].
Gautam actively contributes to the Salesforce discussion platform and currently holds the SMARTIE [Trusted Contributor] position on developer boards. You can follow him through his active blog at http://singhgautam02.blogspot.in/.
In his spare time, he is a backpacker who explores the beauty and heritage of India. If not with Salesforce, you can find him taking part in marathons or expressing his love for dogs.
You can follow him on Twitter at @retweetgautam and he can be found on LinkedIn at http://www.linkedin.com/pub/gautam-singh/24/657/244.
www.PacktPub.com
Support files, eBooks, discount offers, and more
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Free access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view 9 entirely free books. Simply use your login credentials for immediate access.
Instant updates on new Packt books
Get notified! Find out when new books are published by following @PacktEnterprise on Twitter or the Packt Enterprise Facebook page.
Preface
Salesforce.com's platform is one of the most exciting and unique development platforms for business applications. A lot of Salesforce development can be done declaratively without writing code, but to truly master the platform, you'll need to be able to develop not only declaratively, but also with code. Ultimately, you will need to know when to use which toolset—declarative or code.
It is relatively easy, in a world with Salesforce developer forums, Stack Overflow, and user groups, to find others who have faced the same issues you're facing. As a developer, it's likely that you can cobble together a solution from posted solutions. Understanding and tweaking those posts into a solution for your particular problem, however, requires a greater mastery of the platform.
This book is all about mastering the platform; taking your skills as a developer and tuning them for the unique features of the Salesforce platform. We'll discuss the architecture and code and which tool to use for the job. It's going to be awesome. So let's get started…
What this book covers
Chapter 1, A Conceptual Overview of Application Development on the Salesforce1 Platform, is a quick refresher of the Force.com development tools and methodologies. We'll discuss the concepts of classes, triggers, and unit testing that we'll be mastering in the further chapters.
Chapter 2, Architecting Sustainable Triggers Using a Trigger Framework, will dive deep into why you would need a trigger, when you should and should not use a trigger, and how to architect triggers for maintainability. Additionally, we'll dig into trigger frameworks that provide cleaner, more scalable solutions that solve many of the problems that plague traditional trigger development.
Chapter 3, Asynchronous Apex for Fun and Profit, is all about Apex classes that implement the batchable, scheduleable, and queueable interfaces as well as the @future method Annotation.
Chapter 4, Lightning Concepts, discusses the four new features of the Salesforce platform that carry the Lightning moniker. We'll start with Lightning connect and move on to cover process builder, app builder, and lightning components.
Chapter 5, Writing Efficient and Useful Unit Tests, talks about unit testing, which is the single most important activity an application developer has to master. However, writing unit tests is rarely seen as exciting. In this chapter, we'll look at how to write useful unit tests that help us maintain our application over time.
Chapter 6, Deploying Your Code, takes you to the next step—you've written and tested your code, now what? This chapter is a tour of the many ways to deploy your application metadata from one org to another. Specifically, we'll cover the Ant migration toolkit, IDE deployment, and Change sets. Additionally, we'll briefly touch on packaging as a means of deploying metadata.
Chapter 7, Using, Extending, and Creating API Integrations, demonstrates how to use the sObject and bulk APIs provided by Salesforce as well as how to create your own custom REST endpoints with Apex. Finally, we'll build out a set of classes to make calling external REST APIs as painless as possible.
Chapter 8, Team Development with the Salesforce1 Platform, discusses and works through the pitfalls of team development in general and the unique solutions available to us on the Salesforce1 Platform.
Chapter 9, My Way—A Prescriptive Discussion of Application Development on Salesforce1, looks at overarching best practices for Architecture and Engineering of applications on the Force.com platform in depth. Specifically, we discuss the nature of keeping things simple, testing things well, naming things intuitively, and writing maintainable code. While the rest of the book has been descriptive of the best practices, this chapter is an opinionated prescription for developing Salesforce1 applications.
What you need for this book
All you need to get the most out of this book is your brain, your computer with a modern web browser, and a free Salesforce developer org. You can sign up for a free developer org at https://developer.salesforce.com/signup. Of course other tools can help, but they aren't required. Optional tools include Sublime Text 3 (with the MavensMate plugin), Atom (with the MavensMate plugin), and Intellij (with the Illuminated Cloud plugin). Again, these are all completely optional. In later chapters, we'll discuss some JavaScript-related tools but we'll discuss installing them when we get there.
Who this book is for
This book is for Salesforce developers. The more you know about Apex, the more you'll take away from this book. Hopefully, as you master more and more of the platform, you'll be able to revisit this book and take away more each time. Regardless of how much Apex you know, this book can teach us all something about how to master the platform.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the erratasubmissionform link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. A Conceptual Overview of Application Development on the Salesforce1 Platform
This chapter will give you a quick refresher on Force.com development tools and methodologies. We'll discuss the concepts of classes, triggers, and unit testing that we'll be mastering in future chapters. Additionally, we'll discuss the tools available for us to write Salesforce1 code. We'll focus on the developer console built into the Salesforce web interface, and you'll learn to use it for daily development tasks. The following topics will be covered in detail in this chapter:
Developing for the cloud
Starting with e-mail, traditional applications for the desktop have been replaced with browser and mobile-based applications. And just like that, cloud computing has become an everyday fact of our lives. Now, you can find applications on the Web running on your browser that handle everything from photo editing and displaying to music streaming services and, of course, running your business. Corresponding to this shift to cloud-based applications, there's been a shift in how we develop software. True, we are no longer writing software on a local machine, publishing it, and having users run it on a local machine; we're now writing software on our local machine and pushing it to the App Store, the cloud, and increasingly connected devices. Salesforce development has always been somewhat different though. The Salesforce1 platform requires developers not only to run their code in the cloud, but to develop it there as well. This has always been the case to some extent, as you can't run an instance of Salesforce on your local computer. The only way to develop new features, to test, or even run your code is to put that code in the Salesforce cloud. Over the years, Salesforce has continually worked to improve this experience, first with the Eclipse-based Force.com IDE, then with the metadata and tooling APIs that facilitate third-party IDE integrations. Now, Salesforce has created the developer console, an in-browser code editor. We will use a developer console throughout the rest of this book to work through exercises, create and edit metadata, and demonstrate various features of Salesforce cloud. Before you can access the developer console, you'll need a developer edition organization. To sign up for a developer org visit the following URL. I highly encourage you to pause and sign up for the development org. Of course, if you already have a developer org, you can reuse it.
When you go to http://developer.salesforce.com/signup, the signup page will be displayed, as shown in the following screenshot:
Identifying the development tools
There are three main development tools for building Force.com applications. The first and perhaps the most efficient development tool is the Force.com IDE. The IDE is distributed as a plugin for the venerable Eclipse development environment. If you've done Java development, you will feel at home with this. Additionally, in the past few months, an excellent plugin for the venerable Jetbrains Intellij IDEA IDE has been released. It is called Illuminated Cloud (refer to http://www.illuminatedcloud.com/ for more information). If you're a fan of the Intellij platform, you'll feel at home with it. The Salesforce community has also established another tool called MavensMate for developing Salesforce1 applications. MavensMate is a set of plugins for the excellent sublime text and the atom text editors. The plugins use the metadata and tooling APIs to provide a rich set of development tools. These tools include logging, anonymous apex execution, and the creation and editing of metadata. Documentation on installation and use of the MavensMate plugin can be found at the MavensMate home page, http://mavensmate.com/. The developer console is a relatively new feature to Salesforce. It provides an in-browser tool for developers to create and edit metadata, as well as run tests, execute queries, and generally inquire into the state of your application code. You can access the developer console by clicking on your name in the upper right-hand corner of the screen and selecting developer console, as shown here:
At various points, you'll see text items denoted by the pipe symbol( | ), for example, File | New | Class.
Let's take a look at the following screenshot of menu instructions for the developer console:
For example, if you click on the File menu, followed by the new menu item, and finally on the class menu item, you'll be given an opportunity to create, name, and create a new Apex class:
Object-oriented building blocks of Force.com development
The Salesforce1 platform runs the Apex programming language. Like most other contemporary programming languages, Apex is object-oriented. Object-oriented development is focused on the creation of and interaction between objects. Objects are the result of instantiating classes. Classes describe properties and methods that can be interacted with. For instance, you might have a Box class, with properties of height, width, and depth. A box object would refer to a specific instance of the class box, with it's own values for height, width, and depth. Classes are the basic building blocks of object-oriented development and, therefore, Force.com development. Classes come in many varieties, from Visualforce controllers and controller extensions to inner and wrapper classes and normal classes. We will work with a number of class types throughout the book. Each class type can be created via the developer console using the new class option in the file menu and giving it a name.
While classes are building blocks of object-oriented development in the Salesforce1 ecosystem, there are a couple of other code containers, specifically, triggers and lightning bundles. Aside from where the files are stored, the biggest difference between classes and triggers is found in their first line. Classes use the class keyword, whereas triggers use the Trigger keyword:
Triggers differ from classes in that they define reflexive behavior that the system takes in response to certain data manipulation actions. Triggers have their own rules and ecosystems, and we will look at them in detail in their own Chapter 2, Architecting Sustainable Triggers using a Trigger Framework. Lightning Bundles, on, on the other hand contain more than just code. Lightning bundles also contain other assets like CSS style definitions, icons and documentation.
Learning to master Salesforce1 development
There is an old story about a new developer and a seasoned developer tackling the same problem. The new programmer Googles the problem, and after looking at a few stack exchange posts, pastes together some code and is confident that it works. After all, he thinks, other people have this exact same problem and they helpfully posted their results online. With their help, the new developer can put together a solution. On the other hand, the experienced developer first sits down and writes a test to prove that the problem exists. Only then does the developer write code to try to rectify it. This is one of the key differences between being an application developer and a master application developer. This is equally true for Salesforce1 platform. To truly master the platform, you not only need to know the language, logic, and patterns, but also how to know, objectively, when the code is done. Because of this, we'll be focusing on writing automated tests for our code.
Knowing when your code works is paramount to Apex solutions. However, the Salesforce1 platform provides a number of ways to develop solutions without writing Apex. Almost everything that can be done with the declarative tools can be done with Apex code, but to master the platform, you need to know when to use those declarative tools and when to write Apex.
Using the Salesforce developer console
Our code must live in the Salesforce cloud. Throughout this book, there will be a number of example code segments. Each of these is intended to highlight a technique, pattern, or feature of either Apex or the Salesforce1 platform. While you are free to use MavensMate or the Eclipse Force.com IDE plugin, this book will demonstrate code segments that have been tested in the developer console. Because of this, it's probably a wise idea for us take some time and demonstrate how to use the developer console. Once the window opens, you'll see a two-pane interface generally broken down into a taller pane and a shorter one below it. The menu bar across the top pane gives you access to several development features, while the lower pane gives you access to things such as logs and the query editor. Additionally, you can use this lower pane to access the view state of a visual force page and a number of other features as well. Let's talk about some common use cases for the developer console and walk through how to accomplish them.
Opening and creating metadata
Unless you're working with a brand new developer org that contains no metadata, you can open existing pages, classes, and triggers through the use of the file menu. To open up an existing class choose File | Open. You'll see a pop-up window with three panes:
The first pane shows various types of metadata you can open that is Triggers, Classes, Objects, and so on. Once you select a metadata type, the middle pane will populate with all of the files of that type. For instance, if you select classes, you'll see all the classes in the org. You can open up any given metadata file by double-clicking on the name in the middle pane. Additionally, other resources, such as lightning bundles and static resource bundles can be opened using the File menu option, Open Resource. If you've ever used sublime text, this works similarly to the open-anything command. Start typing in the filter modal and it will reduce your selection options helping you find what you're looking for.
Likewise, to create new classes, pages, and triggers use the New menu of the Developer console. The new submenu lists all of the various types of metadata you can create in the console, including things such as Static Resources and Visualforce Components. Ensure that you familiarize yourself with the process of creating new classes, triggers, and Visualforce pages; we will be doing this throughout the book.
Running SOQL and SOSL queries
Across the top of the shorter pane in the developer console is a series of tabs: Logs, Tests, Checkpoints, Query Editor, View State, Progress, and Problems. One of the most important features of the developer console lies in the ability to run SOQL and SOSL queries directly from it. To open the query editor, click on the Query Editor tab. Once opened, you can start typing your query in the lower pane.
Remember that SOQL queries must start with SELECT and SOSL queries must start with FIND when you run a query. After you run a query you'll see the results in the upper pane of the developer console. You can interact with these records by selecting a record and clicking on the command buttons at the bottom of the pane. This allows you to open the record in the Salesforce user interface, or delete the record right there in the developer console, as shown in the following screenshot:
While we're discussing this, let's go ahead and give it a try. Your developer org comes with a certain number of accounts and contacts pre-established. We can run a query right now and experience how the developer console query editor works. Write this query in the query editor of your developer console:
If you're using a new developer org, you'll have between 10 and 12 accounts that are returned as results in the top pane of the developer console. In fact, unless you delete the accounts from your org, this query will always return at least a few records, each column being one of the two fields requested in select clause of the query. Double-click on the Name field of the first record. As soon as you do so, you'll find that you can edit the record name right there. However, once you have edited a field on a record, ensure that you hit the Save record button at the bottom of the pane. You'll also find buttons to insert a new row, access that record in the Salesforce user interface, and open the records detail page.
Running unit tests
Another tab in the bottom pane is the Tests tab. This is where you will run and, otherwise, interact with unit tests. Unit tests are methods of code that we run to execute and test units of live code. We'll talk extensively about unit tests in Chapter 5, Writing Efficient and Useful Unit Tests. Unit tests are run asynchronously, meaning they don't run immediately when you fire them up. You'll need to wait a bit while your tests run and the tests tab will show you when they start. As the test run completes, you'll see that the individual suites are completed and the individual tests are underneath them via disclosure triangles. Should you have a failure, you can double-click on the failure to bring up the results of that particular test in the upper portion of the developer console. Here, you can see the tests tab with the test suites and test methods expanded:
When viewing the Tests tab, an additional data pane shows up in the lower-right corner. While the bottom-left pane allows you to view test runs, the bottom-right pane shows you the code coverage for the various classes and triggers in your org:
This window shows the overall aggregate code coverage metric that matters when deploying from one org to another and you must have at least 75% of your code covered as measured here. As you can see, I don't have anywhere near the code coverage I need. Double-clicking on a class or trigger listed in this code-coverage pane will open the class and display which lines are covered and which are not. This is an incredibly useful tool for finding testing gaps!
Creating and opening Lightning Components
Lightning Components are the building blocks of lightning apps. They're written in JavaScript, Apex, and HTML/CSS; they represent the next evolution of Salesforce application development. If you've enabled Lightning Components in your org, you'll see that the ability to create new Lightning Components is in the same New menu list as classes, triggers, and so on. Specifically, you'll see options to create new lightning apps, Lightning Components, lightning interfaces, and lightning events. However, opening lightning resources is slightly different than opening a Visualforce page or an Apex class. Instead of navigating to File | Open, you have to use the new open lightning resources menu item in your file. We'll talk more about lightning components in Chapter 6, Deploying Your Code.
Opening and reading debug logs and adjusting log levels
One of the great benefits of the developer console is that you can read all of the debug logs that come through your org. Debug logs are log files generated by code execution on the platform. Whenever a user navigates to a Visualforce page or a trigger is run, for instance, the platform generates detailed logs about what happened and how long it took, developers can insert data into these logs using the Apex method, System.debug(string). By default, only debug logs created when your user has taken action are shown on the Logs option. However, you can toggle seeing the debug logs for all users via the Debug menu. Once an event that has generated logs has occurred, you'll see them listed under the Logs tab, as shown here:
Default sorting is by time, with the newest on top; however, you can sort by the username, application, and so on. More importantly, you are able to sort through them by status. To open the log, simply double-click on it. This will open up in the larger pane of the developer console. Alternatively, if you'd like more of a raw view of the log, you can right-click on it and open Raw Log.
Regardless of how you open the log, the more you deal with them, the more you'll realize they can get to be quite large; sometimes, several megabytes in size. To help with this, the developer console has a way for you to alter the log verbosity. These settings are referred to as the log levels and they provide a fairly fine-grained level of control over how verbose the various system components log. To modify the log levels, click on theDebug menu and then selectChange Log Levels:
Here, you can set the general log levels for a given period of time for database (DB) calls, Callouts, Apex Code, Validation (validation rules), Workflow (workflow rules), Profiling and Visualforce, and the System itself. Each log type has seven verbosity levels ranging from ERROR at the lowest verbosity to FINEST at the most verbose. At the most basic, at the least verbose setting of ERROR, only true errors are logged. On the other hand, FINEST logs the most minute details of the code execution:
More importantly, you can set per class and per trigger overrides if you want to debug a specific class or trigger. Increasing the logging verbosity for your troublesome class or trigger can help you highlight performance problems as well as logic issues. In general, while writing code, it's good to leave most log types on INFO but I set workflow and validation rule logging to error, as workflow and validation rules can log quite a lot.
An anonymous Apex execution
Anonymous Apex is probably one
