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

4. 5.3- Test Data

Hey guys. This is section five testing. And this is lecture number three, test data. In this lecture we’ll talk about how to generate test data to be used in our unit tests in order to perform the test methods. Need data in order to function. You need to feed data to the test methods in order to function, in order to perform the tests. But how can we we get these data? First of all, let me go back to our developer console and let me show you what we did until now. We created a test class and inside we have one method. And then the first thing that we did is to create an account. This is the data that this method will test against and then this account will be inserted. So we need data in order to test. But this is just one account and we need our unit test to test against the insertion of more than one account. We’ll see how we can generate this data in this lecture. Let me go back to the slides. It’s also important to know that the data and the salesforce records that are created and test methods are not committed to the database. So even though I can use DML statements against them, in fact they are not committed to the database. They are rolled back when the test finishes execution. And this rollback behavior is handy for testing because you don’t have to clean up your data after the test is done. So this is very important. Using unit tests, I don’t have to go back to salesforce and to delete the records that I have created. So this is not the same as testing in the GUI as the manual testing where I need to go and I need to delete the records that I have created.

By default, Apex don’t have any access to data in your. They just have access to the setup and to the metadata in your, such as the user or profile object. Creating test data makes your tests more robust and prevents the failures that are caused by missing or change data in the. And you can create test data to be used by the test class. This is the good news. We have many different ways that we can use in order to create our test data. And the test classes, we see them now. In fact, we have three different ways. First of all, we can create our test data directly and the test class, this is what we did. But what we did is to create one s object only. We can create more than one. We can use something called factory class to create sample data. So we can create a separate class that is only used to create sample data. And we can call the methods of this class inside our test class. And finally, we can upload test data into static resources in our salesforce. org.

And we can load these resources into our test classes. Let’s see each one of these in detail. The first way is to create our testing data directly in the test class. And to do that we can create a method in the test class. But not this method should not be annotated with the at staff annotation or with a test method keyword. So it’s a regular method inside our test class. Let me give you an example. We have here a trigger and we have it’s a trigger handler class. And we are creating a test class to test this. To do that, this is the test class. As you can see, it starts with the at its test annotation. And then we have the unit test. Notice that the first plan of the unit test is calling another method of the same class. It’s calling insert position record. So let me go to the next slide and let me show you this method. So this method will only do s object creation. So it will only create as object and it will insert a list of position as objects into the position list to insert list. So now we can use this in our main test class. So this is the first way to create testing data. It is directly in the test class. The second way is to create another independent class that is called a factory class. The methods of this class can be called in the unit test. A factory class, as its name implies, is used to generate data.

First of all, it should be in the public or global scope to be visible to the other test classes. This is number one. Number two, it should be defined with the ad is test annotation to be excluded from the testing requirements of salesforce. Number three, it can be called by test method. This is the main purpose of a factory class. And then the method and the factory class should be defined as any regular methods. They should not be defined with the ad is test annotation. And finally, the methods can take parameters and they can return a value. This is an example. On the left side we have the factory class. As you can see, it starts with the ad is test annotation but its methods do not have the ad is test annotation and these can be called in the test classes. This is an example. We have a test class called my test class. As you can see, it is annotated by the ad is test and it has a unit test. You can see the keyword test method and this will call this method. So the first line of this unit test test data factory create test records. And then we are giving two arguments. It is calling in fact this guy here. So this is the name of the class and this is the name of the method.

So by calling this I will have the return value of this method and this will be available in the unit test. The third way allows you to load data in your test classes without writing much code. This way uses the test that Load data method which will return a list of S objects that corresponds to each record inserted. So how can we call this? To call this we need to first create a static resource in our salesforce. org. To do that, we need to prepare a CSV file that contains all of the records that we want inserted. So first of all we create the CSV file and then we have to go to the setup menu, we have to go to the static resources page and then we have to create a new static resource and then we have to choose the CSV file that we did in the first step.

And then we have to upload this file to the static resource. So now the CSV file that contains all the records will be in this static resource. Step three is to load this static resource into our unit test by calling it from the test Load data method. And this will return to us a list of S object that we can use in our unit test. Notice here we have a list of S objects called LS. And then this is calling the method test that Load Data. That takes two arguments. The first one specify the S object type and the second one specify the static resource that we have uploaded. This is an example. This is selv file that we can use when creating the static resource and then we can use this static resource in our unit test. This is the usage of this static resource. So this is a unit test. And then notice that we are calling the test Load data method that will take these two arguments. And then this will default to a list of S objects and this list can be used used as testing data and the unit test. So we have seen the three different ways to create test data. Let’s now jump into salesforce and let me show you these three ways in action.

5. 5.3- Test Data – Demo

This is the developer console. Let’s pick up from where we left off in the previous lecture we have created a test class called account trigger handler test and the role of this test class is to test these two. It will test the account trigger handler class and it will also test the account trigger. It has one method called test insert and the first thing that this method will do is to create a new account and then it will use the test that start test and the test that stop test to insert this. Which means that this will be a fresh set of governor limits. But it does not make a lot of sense to use these for just one record. Typically it should be 200. Why? Because trigger new has a size of 200 records. So let’s say if you are inserting 1000 records trigger that new will divide this into five different chunks. So the test data should be 200. So in this case I need to find a way to create 200 accounts and I need to use this into my unit test to do so. As we have mentioned, we have three different ways.

The first way is to create a method inside the test class. This will be a method without the test annotation and the role of this method is to create our test data. Let’s do that. So it will be a static method and then it will return to me a list of accounts and it will take one parameter which is the number of accounts that should be generated. Now, the first thing that we need to do is to create a list of accounts and then I will use a for loop that will iterate depending on the numb ACC parameter in this method and on each one of these iterations it will create a new account and it will add it to the list. Now I will add this account to the list using the add method. Let me fix this and finally I will return the list. So that’s it. This is the first way. Notice that I did not use the at istas annotation and now I can use this method to create 200 accounts. To do that, let me first change this to a list and now instead of this I will use the method and I will specify 200 accounts. This is step one. I will keep that because I’m using the same variable name. Step two is to change the sock will query result to a list because now I don’t have a single s object.

We have to change this for both the account and the task and we also need to change the filter. So in this case it will be end and it will be MYAC and the same thing for the task. Why? Because this is not one record. We are retrieving a number of records now. So step two is to change the so called query and the variable. Step three is to change the assert method. First of all I will get rid of this one. Why? Because this name is given by the data itself not by the trigger nor by the class it’s given inside the test class so I will remove it and I will keep these two. These are given in the class. So we need to check against these. Notice that a new description from Trigger.

This is from the class itself. And the same thing for the task. But now I need to change this. Instead of checking against one record, I need to check against a list of records. To do that, I will use a for each loop. The first loop will loop through each one of the inserted accounts and it will check against the description field. So let me also change this and this will also be ACC. What ACC is one account record and the inserted ACC list I will do the same for the task so in this case it will be task and inserted task control A and Shift tab. Now what we have, we have two for loops each one will loop using before each loop and it will loop through each one of the inserted accounts and it will check the description feed that should be this one and the same thing for the tasks. So this is the first method, let me click on Save and everything is fine. Now the second method is what is using an independent class that is a factory class and that has only methods to generate test data let’s do that.

So I will call it Test Data factory and then this will be a test class but it will not contain any test methods, it will contain regular ones. What methods it will contain what I will do I will just use this same method but instead of having it inside the test class I will have it inside this factory class so control X and then control V. This is it. But now instead of writing this method inside the test class itself we are writing it inside an independent class an independent factory class that can be used by any one of the test methods. Let me also change this to public and let me save now on the test class and the test insert method I will change this instead of calling this method from this class itself I will call it from the test data factory class. So this class will contain many methods, this is one of them. I can add as many methods that I want the sky will be my limit I can add methods to create a test data for let’s say contacts, for opportunities for any custom object and so on I can also create test data for let’s say accounts plus contacts related to these accounts.

So as I have mentioned I can add as many methods that I want and I can use this as my factory for test data to be used in any one of the test classes. Now, let me show you the third way to create test data. The third way does not involve coding, but instead it involves preparing a CSV file and then uploading this file to a static resource. Let me go to Salesforce. I will search for static resources and then I will create a new one. Let me call this test account and the CSV file that I will upload to this resource is this one. I have made it offline. It contains these account fields and it contains three records. This is of course a CSV file. It’s not an Excel file. Let me choose it here and I will make the cache control public save. Now, how can I call this static resource from my test class? I will go back to the developer console, to the test class, and there I can call a method that is called Test that load data. This method will take two arguments. The first one is the type of S object. So in this case it’s the account S object. And the second one is the name of the static resource.

Let me copy it from here and I will paste it here. This will be between a single code controllass and that’s it. We now have a test class that uses a factory class to get data. And it also can use the test that Load data method to call a static resource that has a number of records. Of course, you can use any one of these. I will use the factory class way because I think this is the best one. Let me click on Save and let me go back to the slides. That’s it. For this lecture, we have learned how to generate test data. We have more than one way. The first way is to use a method within the test class itself, and then to call this method and the unit test.

And then we can generate data by using a separate factory class that has different methods. Each one of these will generate a type of data and we can use this method in our test class. And finally, we can use static resources to upload a CSV file and to use this in our test class. For me, I prefer to use the factory method because it will be just a single class for each one of the test data. So let’s say I need to have a test data for accounts opportunities and for all the custom objects. I can do all of these methods inside this factory class, and I can call them from within any test class. And finally, as usual, thanks for watching.

6. 5.4- Execute Test Classes

Hey guys. This is section five, testing. And this is lecture number four, executing test classes. After explaining about test classes, and after explaining about the importance of these in Salesforce, and after building test classes and building factory classes to generate test data, it’s time to execute test classes. So in this chapter, we talk about how to execute test classes. There are many ways we can use to execute test classes and unit tests. We can use the salesforce setup menu. We can also use the Developer console, the Force IDE on Eclipse, and any other ides like MavensMate. First of all, we’ll talk about how to execute test classes from the Setup page. We have many different options. Here we have a page called Test Execution Page, where we can choose our tests and then we can execute them. We can also go to the Apex Classes page, and then we can run all the tests. And finally, we can click on a specific test class and we can run it from the developer console. We have also different options to run our test classes. We can go to the test menu and we can run all the test classes. We can also specify a new run. And then we can also specify a new suite of test classes. And then we can run the suite. And finally, from the Force IDE, we have to go to the Run menu.

We have to click on the Run configuration, and we select a new Apex test run. And then we specify the project the. And then we specify the debug level. And finally we specify which test classes will be part of this Run configuration. And the final step is to run these test classes. These are the three different options that we will cover. Let’s go to Salesforce and let me show you these in action. First I will go to the Setup menu, and there I will search for testing. And I will click on Apex test execution under develop under build. So on this page, I can choose the test that I want by clicking on select Test. I have two test classes, so in this case, I will only choose the first one because this test class does not contain any unit tests. And I can click on run. Once I click on Run, I will have this test running and the whole unit test in this test class will run. I can also click on the Developer console to open it from here. And I can click on Options to specify the options that I want. I can also run the unit test from the class page. So I will go to the Apex classes and there I will have a list of all my classes. I have two different options here. Either I can click on Run All Tests button, which will run all the tests in my Salesforce. org, or I can click on the test class itself. So in this case, I will click on the Account trigger handler test. And I can run only this test class by clicking on Run Test. So this is the second and third options. In the setup menu, let me run the test from the Apex test execution page.

To do so, I will select the test class account trigger handler test and I will click on Run. I will click now on the test and I can see that the result of this test is passed. Now, how can I know which lines of code this test covered? I need to go to the classes themselves. So I will go to the Apex class. Let me go to this class and let’s see how many lines were covered. So I have 13 out of 13 lines covered by testing. The second option to run my tests is from the developer console. So let me open this. To do so, I need to go to the test menu and from there, I can have different options to run my tests. First of all, I can click on Run Old. This will run old the unit tests and my old I can also click on New Run and specify which classes will be part of this run. So I can specify the test class and the methods the unit tests. I can also specify a suite. A suite is a collection of different tests. And I can also run the suite. I can also go to the test page itself.

So this is the test page. As you can see, on the top right, I have a Run test button. So if I click on this, I can know the result of my test coverage. So let me do that. And to know the result, I need to go to the test tab. There you go. This is the test run and dispatched. If I have any failure, I will see a red X instead of a green check mark. And on the right side, I can see my total test coverage. So based on this test, the one test that I ran, I have 43% coverage. Why? Because I don’t have many classes. I just have the classes that we have made until now. And the one that we were targeting is the account trigger handler class and a trigger. So now to know the lines that were covered by this, I would double click on that. And then I can see the lines. There you go. So the blue lines were covered. And I can know exactly which Apex test class covered these. I can see here. I can see that the account trigger handler test covered 100% of this. I can do the same for the trigger double click and the blue lines were covered. And to check which test class covered it, I can click on that.

And I can see that it’s indeed the account trigger handler test class. Notice if I go back to the class, I can see that I have one system that debug not covered. Why? Because this is not part of the requirements of testing in Salesforce. So I have 100%, and this is not Blue. Notice that I need 75% overall coverage in order to deploy to a production environment or to an application on the App Exchange. If I don’t have that, I cannot deploy anything. Even if I have some classes with zero coverage and the overall is 75%, I can still deploy them. But until now, I cannot because I have many classes without any coverage. And also, another note. If, let’s say, I have this test and any of its assertions failed, even if I have 100% coverage, this test will fail. I will have a red X here, which means that I cannot deploy. I need to have all my unit tests passed. And it’s very important to have all the assertions succeed. Even if I have 100% coverage, but only one assertion fails, I will have this test class fail, and I will not be able to deploy. Now, let me go to the third option, which is the Force IDE.

To run my test, I will click on Run and then Run Configurations. And there I will right click on the Apex test, click on you, and then I will specify the project, which is in this case, this one is@the. org. And I can specify the log levels. And on the test tab, I will choose my test. So I will click on Search and I will choose this one. And I can also choose a test suite. And then I will click on Run. So the test completed. Let me go to the Apex test results. And as you can see, I have a green test, which means that it succeeded. And there I can see the coverage. This is the same thing that I can see in the developer console. And if I have any error, I will go to the Stack trace. These are the three ways that we can use to run our unit test. First of all, we have talked about running these tests from the setup menu and then from the developer console and finally from the Force IDE. Personally, I prefer to run these tests from the developer console. And I also use the developer console to write my Apex code, to write my VisualForce pages, and also to run my tests. So it depends on your taste. But for me, I use the developer console. You can also use any third party IDE like Mavens made, which is a great idea, by the way. And also, there are many other Ides, like Cloud Nine and so on. So this is it for this chapter. And finally, as usual, thanks for warning.