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

1. 5.1- Testing Deployment Requirement and Testing Framework

Hey, guys. This is section five testing. And this is lecture number one testing, deployment Requirement and Testing Framework. In this lecture, we’ll talk about testing in general. We’ll talk about manual versus automatic testing. We’ll talk about testing requirements for deployment and salesforce, and why it is required to first test your code before deployment. And finally, we’ll talk about testing framework and Salesforce course. First of all, why testing is important, why it is a crucial part. Well, with testing, you can make sure that there are no errors in your code. Without testing, there is no way to check if there are errors in your code. With testing, you can make sure that the expected output is working, so you can know exactly if the code worked by testing it. So if you get the expected output, then the code is working. And finally, with testing, you will be able to deploy into the production environment of Salesforce. You cannot deploy your code into the production environment or into an application on the App Exchange without testing it. And without this testing. Passing a testing can be performed either manually through the user interface.

So this is what we did when we tested our trigger in Salesforce. We created some records to check if the trigger worked or not. This is important, but testing through the user interface is prone to errors and it will not catch all of the use cases of the application. So if I go back to Salesforce, I can see that I have a class and I also have a trigger. And to test these, what we did, we went into Salesforce and we created an account, and we compared the output of the account with the expected output using the code. So here we have a trigger with two events before insert and after insert. And each one of these will call a method. And then we trace it back to the class. And then we checked that the description should be this one. And we should have this in the system debug, and also we should have a task. So what we did, we went to Salesforce, we created an account, and we checked that testing can also be performed automatically through something called unit test. These are special classes and methods that are made specially for testing. So they are only made for testing and they automate the testing procedure. So unit tests are class methods that verify whether a particular piece of code is working. And you can think of a test method as Apex code that test other Apex codes. So it’s just an Apex code. It’s used to test other Apex classes and the test will be automatic.

And in Salesforce, testing is required. You are required to test your code before deployment to production or to an application on the App Exchange. So what are the requirements for testing in Salesforce? Apex code can only be written in a sandbox or in a developer organization. And it cannot be written directly into production environment. And after being developed in a sandbox or in a developer environment, your Apex code can either be deployed into your production environment or it can be made into a package that is distributed via the App Exchange. In addition to being critical for quality assurance, apex unit tests are required for deploying and for distributing your Apex code. This is what we have just mentioned. But why? Why it is important to test your code before deploying it to the production environment or before packaging into an appealing this application via the App Exchange. What’s the reason? Well, as we have mentioned before, Salesforce runs in a multitenant environment, which means that you are sharing one Salesforce instance with many other orgs. So it can go up to thousands of orgs.

Which means that you don’t own the Salesforce instance. And Salesforce needs to make sure that your code does not break this instance. And how this can be done? This can be done only through testing. So this is why testing is a requirement before deployment to production environment and to an application in the App Exchange. So now, in order to be able to deploy your Apex to production to the App Exchange, many steps should be done. First of all, at least 75% of your entire Salesforce. org Apex code must be covered by unit tests. So, let’s say you have 100 Apex classes and you have 50 Apex triggers. And the total lines of code is, let’s say, 1000. So in this case, you need to have at least 750 lines of code covered. So how this is done, when deploying to production, each one of the unit tests in your is executed. And after that the result is given. And if the coverage is not more than 75%, you will not be able to deploy. Note that calls to the system that debug are not counted as part of the Apex code coverage and test methods and test classes are not counted as part of the Apex code coverage. And also each one of the unit tests must pass.

So, if you have a test that fails, you will not be able to deploy to production. Each trigger must have at least some coverage. So if you have a trigger without any coverage, you will not be able to deploy. And finally, all classes and triggers must compile successfully. So, how Salesforce calculates the coverage? The code coverage is calculated by dividing the number of unique Apex code lines that were executed during the test method execution by the number of the total Apex code lines and all of your triggers and all of your classes. So, let’s say you have, as we have mentioned, 1000 alliance and all of your classes and triggers, and the test covered 750. You would have 75%. So, to conclude about testing requirements in Salesforce, testing is required before deploying into the production environment or before deploying into an application into the App Exchange. Why? Because you are, in fact, sharing one Salesforce instance with many other roles.

And Salesforce needs to make sure that your code does not break this instance. And the only way to do that is by forcing testing. But you should not think of testing as just a requirement for deployment. Of course not. You should think of testing and of unit test as this automatic tool that Salesforce provide to you to make your life much more easier. So just compare testing and the GUI for each one of the classes and of the trigger versus testing by the unit test. Of course, testing by unit test will take a little bit more time, but it’s much more convenient and effective. Now, how can we execute the unit test in Salesforce? What’s the testing framework in Salesforce? There are many different ways to execute the unit test. First of all, we can do that via the setup menu, the setup page. We can go to the Apex test execution page. We can go to the Apex class page list, and then we can run all of the tests. And finally, we can go to a specific Apex class. And then we can run a specific test. We can also use the developer console to run the unit tests. Finally we can use the force IDE or any other ides like maintenance mate. So in this lecture, you have learned about testing, about the importance of testing. What are the testing requirements for deployment to a production environment and to an application on the App Exchange? And finally, what are the different testing tools that we can use in Salesforce? And finally, as usual, thanks for watching.

2. 5.2- Write Apex Unit Tests.

Hey, guys. This is section five testing. And this is lecture number two, writing Apex Unit Test. And the first lecture of this section, we have talked about testing in general. We have talked about automatic versus unit testing. And we have talked about why it is important to test our code before deployment, to production and to application and the app exchange. And finally, we have shown you that there are many different options where we can create unit tests. In this lecture, we’ll talk about how can we create these unit tests. First of all, what is an Apex Unit test? An Apex Unit test is a piece of code that is used to test another Apex code so it can test Apex class, Apex triggers and so on. Apex Unit tests are defined as methods and test classes which execute functionalities that is written in Apex Triggers and in Apex classes. So they are used to test these classes and these triggers by executing them. Apex Unit tests are just methods that are contained in separate classes that are called test classes and which are specifically created for that purpose. Apex Unit tests do not commit anything to the database. So even if you have a DML statement in the Apex Unit Test, in fact, this will not be committed. They don’t send any email. They are always flagged with the keyword test method or add is test annotation. And they must always be defined in a test class, which is defined by using the at istest annotation. By itself. They are always defined as static methods.

And finally, they take no arguments. Now, what’s the syntax of an Apex Unit test? To understand the syntax of an Apex Unit test, I will give you two examples. On the left side, as you can see, I have a method called my test. This is a void method. It does not return anything and it is flagged by the test method keyword. So this means that this is a unit test. So this should also be part of a class that is a test class. So in this case, we can define this by the keyword test. We can do the same thing, but in this case, we are using the same annotation on the method level. So instead of using the test method keyword, we use the at is test before the static keyword. So this is exactly the same as this. These two are exactly equivalent. We can either use the test method keyword or we can use the at annotation on the method level. But these methods should be part of a test class. So in this case, we can only use the ad test annotation at the beginning of the class. Apex Unit Test should contain code that is used to test other Apex code. So it can be used to test Apex classes and Apex triggers. When building an Apex Unit test, you have to think of what you would normally do in a graphical user interface. So how do you test, let’s say, a class or a trigger and the GUI? And then you replicate the same thing by using code and the unit test. Let me give you some examples. Let’s say you want to test an Apex class. You want to test one of its method. What you would do, you would open the Execute Anonymous window and then you will call this method. After that, you will compare the actual output of this method with the expected output. All of that is time consuming and it will in fact commit to the database. What you would do instead, you would translate all the steps that you have done to the code that is written inside your Apex unit test. Another example, if you want to, let’s say, test an account trigger before insert or before update a trigger. What you would do you would in fact create an account.

And then you will see the result of this account creation and you will compare the output with the output that is expected from the trigger. So this is time consuming and this will commit to the database. What you would do instead, you would translate these steps into code and you would put these lines of code inside the Apex unit test. But now, how can you compare the output result of a unit test with the expected result? Let’s say you created an account using the unit test. But how can we compare the expected result of this account trigger with the actual result? Let’s see. Next. To do that, we use something called System Assert methods. Until now, we have just covered the Apex code coverage with testing. So we have mentioned that you have to think of what you need to do in testing and you have to translate this into code. And you have to put this code inside your unit test. We still did not compare the actual result with the expected result. And it’s very important to test for different inputs and compare the different outputs. So if, let’s say, an input of x should give me an output of A, I need to be able to test that. To do so, we use the System Assert methods. These methods are used to verify that the method that we are testing works as expected. We have different types of System Assert methods. First of all, we have the system that assert. And then we give a condition. And then we can give an optional message. This method will assert that the specified condition is true. So the condition that it will be taken as an argument, if it is true, the system that assert will return through. Another type of System assert is the system that assert equals. So in this type, we give two arguments. So the expected result and the actual result. If these two matches, this will return through. And we also have an optional error message. And finally, we have the third type of system assert method. It’s the system that assert, not equals. So this will return through if the expected and the actual values are in fact not equal. And we can also get an optional error message. So when we should use the system assured methods, we should use these to verify as many possible scenarios as we can.

So we can test the positive test case and we can also check the negative test case. We can also use test that start test and test that stop test inside our Apex unit code. These are system static methods that are provided by Apex. These methods will separate the governor limits and they will give us a new fresh set of governor limits whenever we execute our test. So before test execution, right before test execution we can invoke the system that start test method and then we can invoke the test execution. And right after the execution we can invoke the test that stopped us. So the execution will have a fresh set of governor limits. So the test that start test will mark the point in your code when the test begins. The test that stop test will mark the point in your code when the test will end. The test that start test is used in conjunction with the stop test method. And this method is of course used in conjunction with that one. Each test method and your test classes is just allowed to call the test start test and the test that stop test only once. So we cannot call it more than once. Inside one unit test. The code that is written before the test that start test and the unit test will be used to initiate the variables, to populate the data structures and so on. And after calling the test that start test method, we will get a new fresh set of governor limits. So in this case, we can test against government and limits inside our Apex unit test. So as you can recall, we have a class handler that is used by the trigger on the account object. This trigger will take before insert and after insert the event. And each one of these will invoke a method and the class handler, account trigger handler. The first one, the first method, it will do what? It will add a new description to the description field.

The second one will create a task that is linked to the account that was created. Now how we can test that? To test that, let’s build a unit test. So this is the test class and the test method. As you can see, I started this class by the annotation at its test to mark that this is a test class. And then the name of this test class is Account Trigger Handle Test. And after that I have a method that is called Test insert. And this is a void method and it’s also a static method and it’s preceded by the annotation is test. Now, what I should put inside this unit test. If you can think of how we tested the trigger. We just created an account. And then when we did that, we went to the graphical user interface and we checked if the account indeed has the description feed and if a task was created. So let’s do the same by using code. How to do that? First of all, we need to create an account. So by using code, how we can create an account? We can use account t ACC and a new account. And then we have to provide the mandatory feed. In this case, it would be the name field. And after that I use both methods. A test that start test and test stop test to annotate my actual test. So by inserting this account, this will be my test. After insertion, I need to go and check. So this is exactly what we did in the UI. We have inserted our account and then we have opened the account page to check if indeed the description field was added and if a task was created. How to do that? First of all, we need to retrieve the account from salesforce. To do that, we use a sockwell query. So this is the Socalled query it will take where ID equals to TACC ID. So this is the ID of this guy. And this will give me the account variable inserted account. And then I use the system that assert equals method to test whether the expected result test account is in fact the actual value of the inserted account that name field. So if these two are the same, this would return true. And then I did the same thing for the description field, I checked whether the expected value is the same as the actual value. And finally I tested the task. So as part of this trigger, a task should be created. First of all, I use a sockwell query to extract this task.

So select ID from task where what ID is equals to the t account ID. And then I used this and the system that assert equals method to test whether the subject of this task is the same. So I use this method to check whether the expected result that is a new account auto task is equal as the subject field and the TATC task. So if this is true, then the system that assert equals will return it through. Now, by only having the insert TATC without having any assert method, I will have my whole code covered. But to make sure that the expected result is same as the actual result, I need to use the system that assert method. So this is for my own benefit. Now, what are the best practices of Apex unit tests? First of all, we need to cover 100% of our Apex code.

So as you can remember, we have to cover 75% to be able to deploy to the production environment or to an application on the app exchange. But for our own good we have to aim for 100%. Also, it’s a best practice to use the system assert methods even though they are not required to be able to deploy into the production environment. But for our own good we have to use them. We should also use the system as well methods to check both for the positive and for the negative test scenarios. We should also use the start test and the Stop test. This is very important because by using these we are sure that we’ll have a new set of governor limits within them. And this is very important to test against governor limits. And finally, we have to build different methods in our test classes. Some will be there to test against positive scenarios and others will be there to test against negative scenarios. Now let’s go to salesforce and let me show you how to create a test class.

3. 5.2- Write Apex Unit Tests – Demo

So I will go to the developer console and then just like we created a regular class we can use a new apex class and let’s call this account trigger and it’s also best practice to use the same class name followed by the keyword test to denote that this is a test class for this class. So as you can see here I have the account trigger handler class and now I have the same name that is followed by the keyword test to denote that this is the test class for this class. So there we go we have the definition of the class, public class and the name of the class. So the first thing that we need to do is to use the add istest annotation to denote that this is a test class and then let’s create the different methods of this class, the different unit tests. First let’s create the first method so at istas so we’ll use the same annotation and then will define the method. Note that this should be a static method, a void method, it should not return anything and it cannot take any arguments. Now at the body of this method. First of all, as we have mentioned, we have to create an account to be able to test this class to do so. And then we’ll use the test that start test method to give a new fresh set of govern limits and then we will insert my ACC and then we’ll use the test that stop test method. So now what happens if I run this without any assertion method? If I run this test what will happen? A new account will get created with the name Test account and then it will be inserted. By inserting this account this trigger will fire. Because this is a before insert trigger the method of this trigger will fire and even this one will also fire. So I will have these lines covered and also by using these lines I will call a method and the account trigger handler class. So this is the first one and this is the second one so this will call that which means that this test will also cover this method so let’s go there. So this will be covered and as a result, the body of this method will also be covered. And that one also will be covered. And as a result, the body of this method will also be covered. So in this case, by just invoking the DML operation insert my ACC, I will have these lines covered and also as a result, these lines will also be covered.

So this will cover my entire lines of code, of the trigger and of the class. But this is not a best practice. We need to also check if indeed the new account has the description as in the class and it also has a new task with this subject and so on. To do that we use the system as cert methods so this is not a requirement for deployment. So if we stop here, we will have the requirements met. We will have more than 75% of the lines of code of these two covered and we can deploy to the production environment. But to make sure that the output is really right, we need to check the fields. And to do so, we need to use the system assert method. Let’s do that. First of all, let’s fetch this inserted account from the database this was inserted and now it’s time to fetch it. To do that we will have an s object called Inserted ACC and this will call a sockwell query. So select what feeds I need I need the ID field, I need the name feed and I need the description field from account where ID is equals to we use here a variable so we have to use the semicolon MYAC ID. So this is the same as this one here I have my ACC so I need to get the ID of this and I need to give this as a filter to the soccer query.

Let me fix this so this is select. Now let me extract the task of this task inserted task. So also I will use a sokol query so this sock will query will return a task.

So this is the inserted task and we have used this so called query to get this task. And notice here the filter is what ID, which is the ID that the task links to should be the account that we have just inserted. And now let’s use the system assert methods. So this is the method and we’ll use three such methods. So I will copy this and I will paste it three times CTRL a and shift tab. So first of all I need to check the name of the account so the expected is test account and the one that the System Assert method will check is the inserted ACC name. So this is what this is from the sockwell query and this is the name that was received by sockwell. So let’s do the same for the description field. So if I go to the class the description should be this one so I will copy this and I will paste it in my test method. And finally for the task let’s go to the task and let’s see the subject of the task. So this is the subject that should be in the task and it will test against insert a task subject.

So this is our test class. As you can see, we have created an account, we have inserted it, and then we have used the Socalled queries to retrieve it and retrieve the task that was inserted by it. And finally, we have used the system that assert method to check the results, control us. And in a later lecture of this section, we will run this test and we’ll see where we can run it. Let me go back to the slides. So, as a summary in this lecture, we have learned about the unit test syntax. We have learned about the assurance methods and the unit test. We have learned about the test start test and the test stop test method. And finally, we have talked about the best practices that we should use in a unit test. And then we have jumped into salesforce and I have shown you how to create a unit test. And finally, as usual, thanks for watching.