CRT-450 Salesforce Certified Platform Developer – Testing, Debugging and Deployment – 17% Part 3

7. 5.5- Invoking Apex in Execute Anonymous vs. Unit Tests

Hey, guys. This is section five testing, and this is lecture number five invoking Apex and Execute Anonymous versus unit tests. And this lecture will mainly talk about the difference between writing Apex and invoking it in an Execute Anonymous block versus writing it and invoking it in a unit test. First of all, let’s start with the Execute Anonymous. The Execute Anonymous as the ability to run any line of Apex code, just like the ability to run any line of Java code and the public static void main. So we don’t need to define a class. We don’t need to find anything. We just go ahead and we type our Apex code and we run it. So this is the main goal of the Execute Anonymous. Do not confuse this with logging in anonymously and running any Apex code. You always have to log in to Salesforce to be able to run your code and Execute Anonymous. And running and execute Anonymous will depend on your permissions, as we’ll see later on when you run some Apex lines of code and the Execute Anonymous block. And these lines create metadata. So let’s say your lines of code created a class, this class or this metadata is not saved into your salesforce. org.

And finally, you can run Execute Anonymous block through the developer console, through the force IDE, through the workbench, through any third party IDE, and through the sub API calls. The return result for an Execute Anonymous block includes the status information for the compile and for the execute phase of the code. And this includes any errors that might occur. It also includes the debug block content, including the output of any calls to the system that debug. So let’s say you have executed some lines of code using the Execute An element. You will get the compile result and any errors that might occur, and you will get the execution of these lines of code. And you will also get a debug log. So you can see the content of the debug log, including any call to the system that debug method that you have entered, and the lines of code. You can type absolutely any Apex code and the Execute Anonymous block, and you can also call any existing class in your salesforce. org. You can also define classes using the Execute Anonymous block.

But as we have mentioned, these are mainly metadata and they are not saved to the salesforce. org. If you execute the anonymous block and it compiles and it completes successfully, any database changes that you put in your lines of code are automatically committed to the salesforce. org. If the anonymous block does not complete successfully, any changes that were made to the database are rolled back. Unlike the classes and triggers anonymous blocks. Execute and User Mode as you can recall from a previous lecture, salesforce runs in two different modes. First of all, we have the system mode and the system mode. We don’t have any restrictions. We have access to all the records and all the permission, triggers and classes run in this mode. But a user mode execution depends on the logged end user. All of the logged end users objects and field level permissions are imposed. So you cannot change anything that you cannot change in the GUI. If you can change something in the GUI, you can do the same and Execute Anonymous block.

Now, let’s talk about invoking Apex and unit tests. Unit tests are mandatory to deploy to the production environment and to package an application. And the app exchange. They are here to automate your testing. And they are used to calculate the code coverage, which should be at least 75%. Unit tests are executed in system mode. So the logged end user object and feed level permissions are totally ignored. And you can have access to all of the salesforce object and to all of the salesforce fields. And with unit tests, any changes that are made to the records are not committed to the organization database. This is a table that shows the difference between invoking Apex and Execute Anonymous versus invoking It and unit tests. First of all, the sharing mode and Execute Anonymous as user mode, which means that we are bound to the permissions and to the record access of the logged end user. But in unit test this is not the case. It’s the system mode, which means we don’t care about the logged end user permissions and record access. The lines of code and Execute Anonymous block are not saved, but in a unit test they are saved. They should be saved in a test class.

Any data that is produced by an Execute Anonymous block is saved and is committed to the database if the block succeeds. But this is not the case in unit test. Any data that is produced by a unit test is not saved to the database and it is rolled back when the test ends. The output of an Execute Anonymous is listed in the debug log, but the output of a unit test cannot be seen. It can only be used in test coverage. Execute Anonymous are subject to the normal synchronous governor limits. But in unit test we can control that. We can use the test that start test and the test that stopped us to give us a new fresh governor limit set. And finally, because Execute Anonymous runs in user mode, calls are always made under your own login information. But this is not the case in unit test.

In unit test you can use something called system that run as method to pretend to be another user to test against another user. So let me go to salesforce and let me show you the difference between these two. So, first of all, on the developer console and to open the Execute Anonymous window, we have to go to the debug menu item. And then we choose the first item which is the open Execute Anonymous window or simply we can hit Control plus E. We’ve been doing this throughout this course and then we can write any code here. So integer I equal one and then let’s use this to add this to the debug and execute. So in this case I will have a debug log with this and I can see the debug log and I can click on this to see the output. And I can also call any class here. So any class in salesforce, I can call it here. But note that this code is not saved. I don’t have any facility to save this code and if I create a class here, it’s not saved to my salesforce. org.

But if I do anything here, if I commit anything. So let’s say I create a new account. So account A equal new account and let’s say name equals new account. So if I use a DML statement here, insert A, and if I execute this, and if I don’t have any compilation error, this will execute and this will be committed to my salesforce order. Let’s try this. So, execution succeeded. Let me open salesforce. Now I will go to the account object and I will see that I have the new account. There you go. So this is very important. Anything that I type here, any code and any DML statement is committed to the database. Now I will show you the execute anonymous from the Force IDE. So I will open Eclipse and I will make sure that this is refreshed and it is online. So to execute anonymous, I can go to the force menu item and I can click on this item. So let’s try to execute this. I’m creating a new account which has the name new account B. And then I’m using a DML statement to insert this account into my salesforce. org. This is the debug log, just like the developer console, execute anonymous at node. I have this. Why? Because this is from the trigger.

Now let me go to the salesforce. org and let me check if this was created. There you go. Now let me go back to the developer console and let me show you briefly about the unit test. This is what we did in the previous lecture. So to execute a test, I would just open the test class itself and I can execute it. Let me do something more here. Let me try to change my test class. So in this case, I will go to the test class, which is this one, and I will make it wrong. What I will do, I will just add this here and control us. Now what will happen? This assertion will fail the test where he said because I’m changing this test and let me try to execute this test, I will run this. When I run this test, none of the output is committed to the database. So even though I’m creating 200 accounts, none of them will be committed and they will be rolled back when the test ends. So if the test is successful or not, they will be rolled back. Let me try to run this, and this will give me an error, even though this test will cover all the lines of this class and of this trigger. But I have one assertion that will fail. Let’s see what will happen. There you go. We have our coverage 100% on the trigger and on the class. But we have here a red XMark. Why? Because this assertion failed. So I will double click and I can see that assertion failed. We were expecting this, but instead we got that.

So to fix this, I will revert it back to the right expected result, which is from this class. So this is just to show you that even if one assertion fails, the whole test will fail. And even if I have 100% coverage, I cannot deploy to the production environment because this test failed. Let me save this control s, and I will run the test again. And there you go. Now the test succeeded. So the whole point of this is to show you that none of these accounts were committed. Let’s go to salesforce and let’s see if they were committed or not. I don’t have any of them. And to also show you that if I change one assertion, I did miss that at the previous lecture, so I’m covering it here. The whole test will fail and I cannot deploy to the production environment. So this was the difference between invoking Apex and Execute Anonymous versus invoking Apex and Unit test. We have seen that there are many differences. Mainly, Execute Anonymous runs in user mode and it commits anything to the database. But Unit tests run in system mode and they don’t commit anything to the database. And finally, as usual, thanks for watching.

8. 6.1- Monitor and Access Debug Logs

Hey guys. This is section six, debug and Deployment Tools. And this is lecture number one, monitor and Access Debug Logs. This lecture will talk about debug logs. What are they, what are their benefits, how we can set them up, and how we can access them. First of all, what is a debug log? A debug log records database operations, system processes and errors that occur when executing a transaction or while running unit tests. A debug log helps in debugging issues such as database changes, http call outs, Apex errors, workflow rules, assignment rules, approval processes, and validation rules. So, to make it simple, a debug log will record anything that is related to this list. So anything that’s related to the database changes, Apex errors, approval processes and so on. When executing a transaction or while running a unit test. Debug log can be set up and viewed on the Setup page under Developer Console and the Force IDE. They can be filtered as they are generated to get specific information. Under Log, they contain a customizable level of information. So you can customize what level of information you want to see in a debug log. And finally, they have size limits.

They have two MB size limits per each log and 50 MB debug logs for the whole organization. First of all, you can set up ads. You can access debug logs directly on the setup page. To do so, you have to first set up a trace flag. A trace flag is simply these three entities. First of all, we have the traced entity. This is the entity that we are following. It can be an Apex class, it can be a trigger, it can be a user, and so on. Second, we have to set up the start and the expiration date of the trace flag. And finally, we have to set up the debug level. So this is the page. First of all, we have to set up the traced entity. It can be a user, it can be Apexplat and so on, and then the start and the end date. And finally the debug level. We can access these from the Setup menu under Monitor and under Logs. debugs Level will specify the amount of information that are recorded in the debug log for each one of its categories. Categories can be system workflow, they can be validation rules, they can be call outs and so on. So, as you can see here, we have different categories. And then we can specify for each one of these the level that will be recorded. And the combination of category and level will specify which events will get logged. And this will be the debug levels. Now, we can also set up and we can also access debug logs and the Developer Console. The same debug log output can be accessed from the Developer console by going to the Logs tab. So, as we can see here, we have the debug menu and there we can change the log levels. This is the same thing that we can do on the setup page.

And then using the Logs tab, we can see the different logs and we can double click on the logs to see the output of the log. Also on the developer console, we can specify trace flags. We can specify what we need to follow, what we need to track, like Apex class, like a user, like a trigger and so on. And also debug level can be specified, they can be defined. So this is the same thing that we can do on the setup page. Now let’s go to salesforce and let’s see debug logs in action. To access the debug logs, we have to go to Monitor and then to logs. And then we can see these two links. Let me click on this first one. As you can see, this is the trace flags section.

We have one default trace flag and we can create a new flag. Let’s create a new flag. So the first step is to choose what we need to follow. So we can choose a user, Apex class, trigger, automated process and so on. So let’s choose a user and then we have to choose the user. So in this case, I would choose this user and then the start and the end date. Note that we can only have a 24 hours period. We cannot have more than that. And finally, we have to specify the log level. We can choose the default one, which is this one, or we can create a new one. So let’s now choose this one and let’s click on Save. So now we are following this user by defining F flag. Let me now show you how we can define new levels. Let me click on the Levels link. And there we have one default debug level. We can also create a new one. Let me create a new one. And there I will first give it a name, new level.

And then for each one of the categories, I can specify the level that I want. So database this will record all of that. So anything that gets executed from this list will be recorded. And I can specify either none info or finest. I can do the same for all the other categories. So for the workflow, I can also do the same for the validation rules, for the call outs, for the Apex code, apex profiling, VF pages system and Wave. So let me go to the validation and let me make sure that it has the highest one. And I will click on save. I know that I can only have API names here. So for that I need to use underscore instead of space. Now we have two levels. We can use these levels and the trace flags. Now we have defined one trace flag, which is this one. And we can edit it and we can delete it. So if I click on Edit, I can see that I can also change the level. So let me keep this one.

And now let me show you how we can check these logs. So what I will do now, I will go to, let’s say Contacts and then I will check the validation rules and I will create a new rule. Let’s say that one of the fields of the contact object should not be blank. So let me check what fees we can use. Let’s go to the mobile. So we will hold this mobile not blank. And then I will use the ISBLANK function to specify that this is the error expression. So this validation rule will not allow this field to be blank and the error message will be and I will save. Now I will go back to the contact page, I will choose any contact, I will edit this and note that the mobile will now be blank. I will try to save and I cannot. Now I will go back to the debug logs and I will refresh this page. Note what we have. Now we have a new log that was generated. To check it we click on View. We can also download it and we can delete it. Let’s click on View and note in this log I can see what happened because I’m tracing the validation rule. You can see that this validation rule was executed and it prevented the saving of this record. So this is how we can use the debug log to trace different events that are happening on the salesforce. org. Now let me go to the developer console. This is the developer console. To check the logs we have to go to the Log tab and then we can also create a new trace flags and new log levels from the debug menu item. We have to go there and we have to click on the change log levels.

Once we are there, we can see the trace flags that we have for the users and for the classes and triggers. And we can also create a new debug level. To do that, let’s click on Add change. As you can see, now we have two levels. This one we have made on the setup page. To create a new level we click on Add. First we have to specify the name. Let’s say New level Two. And then we specify the details of each one of the categories. So let’s say I just want this level to take care of the database operations. So this will be the finest and then everything else will be none. And I will change the name to be, let’s say DB finest level. So now I have an extra debug level that I can use. I can also add a flag. So either I can add a flag on the class or on the trigger. To do so I will click on Add and I will select the class or the trigger and then I will specify the level. There you go.

And finally I can do the same for the user. So I can add a user, but in this case I need to add it by the ID. So this is the exact same thing as on the setup page. But the whole point is that we can do the same on the developer console and not also if we run the execute anonymous. So let’s say and then we execute this. This is the debug. We can filter it by using the debug only. We can also search. So let’s say I want to check the DML governor limit, so I can check that the number of DML statements are zero out of 150 and the number of DML rows are zero out of 10,000. So this is mainly to filter my debug log. And I can also right click and open it. I can also download it, I can open it as a row. So there we go. This is the exact same thing as we saw on the setup page and we can also download it. There we go. So that’s it for this lecture. In this lecture we have learned about debug logs. What are they, how we can set them up in the setup page and how we can do the same, and the developer console, how we can access them and what are their benefits. And finally, as usual, thanks for watching.

9. 6.2- Developer Console, Workbench and Force.com IDE

Hey, guys. This is Section Six Debug and deployment tools. And this is lecture number two. Developer Console workbench and force. IDE. And this lecture will explain the features, capabilities and use case of the Developer Console Workbench and the Force IDE. First of all, before starting with each one of these tools, you have to know that these three tools are all tools that use the API. The Salesforce. org Edition should be API enabled for these tools to run. The API enables editions are Enterprise edition or above and Developer edition. First of all, let’s start by the Developer Console. This is a browser based IDE. It is provided by Salesforce as part of the Salesforce. org and it connects only to one and only one. Using this tool, you can perform many development tasks. You can create and edit Apex classes. You can also create and edit Apex triggers, lightning components, VF pages, VF components. You can run a test against your Apex code. You can write and execute soquel and SOSL queries. You can run codes inside the Execute Anonymous block. You can generate logs.

And you can identify and resolve errors by setting checkpoints in your Apex code. Now, when can you use this tool? You can use this tool when you don’t have any IDE installed on your PC and when you cannot install any ID on your PC. Why? Because Developer Console is a cloud based IDE. When you only need to connect to one at a time, when you don’t need version control, this is controlling the versioning of your code. So this is not available in the Developer Console and finally, when you don’t need conflict resolution. Now, the second tool that we’ll talk about is the Workbench. The Word Branch is a powerful web based suite of tools that are designed for admins and developers to interact with salesforce. com. Org via the force APIs. This tool is made by Salesforce, but it’s not officially supported by Salesforce. And this is basically a website. It’s a cloud based tool. So it’s a website that you can visit. So you have to go to Workbench developerforward. com and then you have to use your own Salesforce. org username and password. And if you are connected to a Salesforce. org and you open this tool, you will log in directly without providing this. So it will use the SSO. Now, what can you do with this tool? Workbench can perform many development tasks such as getting the metadata info about the objects in your so you can get the attributes, the feeds, the record types, the relationships and so on. You can run SOQL and SOSL queries. You can also run DMR operations.

You can run insert, update, absurd, delete and so on using a single record that you specify its field values, or using a CSV file containing a list of records to perform action against. You can also deploy and retrieve metadata to the that you are connected to. And also you can run Execute Anonymous blocks you can set and deset passwords and finally you can have rest bulk and metadata API status. Workbench is best used for getting metadata information about all the objects in My, about their fields, about the record types, about the relationships among the objects in My. And it’s also used for an easier construction of sockwell and SSL queries. Why? Because it has a small user interface that can be used to construct sockwell and SOSL query as opposed to writing them. Now, the final tool that we’ll talk about is the Force IDE. The force IDE is an applicationbased IDE. It is built on top of the open source Eclipse platform and it is available as a plugin inside Eclipse. The plugin for Eclipse interacts with the salesforce. com org.

So using this plugin inside Eclipse, I can have the interaction between Eclipse and between My salesforce. org. The Force IDE can connect to more than one. So this is not the same case as Workbench and as the developer console. Downloading an orgs metadata to Force IDE is done by opening a Force IDE project by providing the credentials. And this is done through the Metadata API. When opening a four. com Ideproject. org organization, you can select which metadata you want to have. You can select any metadata component from the metadata menu and the metadata code of each metadata component shows, for example, the metadata of object as XML. So I can choose what metadata I want in My, and then if I click on the metadata, I can see the details of this metadata as XML. Eclipse has many perspectives based on the plugin being used. Eclipse is an open source IDE. It is used for different types of development. It can be used for Java development, for C hash, for force and so on. And each one of these has its own perspective.

Now, what are the features and capabilities of the Force IDE? It can perform many development tasks that can be done by the developer console, like creating and editing Apex classes, triggers, Lightning components, VF pages and components like running tests, like writing so cool and so on. On top of that, it can do many things. It can archive and export your configuration metadata, which is the information that specifies how is your data set and what are the fields, the repos, the objects and so on. It can modify metadata components and save to your salesforce. org and it can deploy your metadata to other. The use cases of the Force IDE are a project based development deployment from any to any other because you can connect to more than one at a time. You can deploy it to another, synchronizing changes between the installation of the Force IDE and the salesforce. org, and finally selecting only the metadata components that you need. So whenever you connect to a new salesforce all using the Force IDE, you can choose which metadata you want. This is a table comparing these three tools. First of all, regarding installation only the Force IDE needs installation because this is an application based IDE. Developer Console and Work Branch are cloud based and they don’t need installation. Force IDE is of course not cloud based regarding Sokl and SOSL execution. All of these three tools can run So cool and SOSL, but the Force ID cannot run SOSL. Workbench can export the query result in a CSV file. It is not available in the Developer Console nor in the Force IDE. All of these three tools can run anonymous Apex blocks. We can run our test, and we can also debug Apex using the Developer Console and the Force IDE. And it’s not available in the Workbench. We can get metadata information using the Workbench and to some extent using the Force IDE.

And finally, we can connect to more than one only using the Force IDE. And we can deploy from one to another, of course, using the Force IDE. So, as a conclusion, the Developer Console is best used for a quick one development. And you don’t need to install any IDE on your PC. But the drawback is that it only connects to one. It does not have any version controlled, and it does not have any conflict resolution. You can use the Workbench for getting metadata information of all your salesforce objects, for an easier construction of Sockl and SOSL query. And if you want to export the Sock will and the SOSL query, you can do that using the World Branch. But the limitation of the World Branch is that it’s not an officially supported product by Salesforce. And finally, the Force ID is best used for project based development, for deployment from an. org to another, for synchronizing changes, and finally for selecting only the components that you want, the metadata components that you want. And the limitations of this tool is that it needs installation. It’s not a cloud based tool, it’s heavy on the PC resources and it does not at any autocompletion. Let’s now go to Salesforce and let’s see these three tools in action.