 Hello everyone, I'm Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. In this video, I'm going to discuss about Apex test classes related interview Q&A. So if you are giving any Salesforce interview as a fresher or as an experience candidate, so I hope these questions and answers will help you to prepare for that. So first question is, what is Apex test class? So the answer will be the Apex testing framework enables you to write and execute tests for your Apex classes and triggers on the lightning platform. Apex unit tests ensure high quality for your Apex code and let you meet requirement for deploying Apex. Apex code can only be written in a sandbox environment or a developer or not in production. So this is important. So in real time projects, basically we create sandbox copy by cloning production. So all the build or development thing we do in the sandbox environment. So test classes are also built in sandbox and then you can deploy them to production. Apex unit tests are required for deploying and distributing Apex. So if you have implemented any Apex class, and if you want to deploy that Apex class from sandbox to production, or you want to distribute that as a part of package, app exchange package, then that Apex class must be having a test class implemented. Benefits of Apex unit tests. So ensuring that your Apex classes are and triggers work as expected. Having a suit of regression tests that can be rerun every time classes and triggers are updated to ensure that future updates you make to your app don't break existing functionality. Meeting the code coverage requirements for deploying Apex to production or distribution, distributing Apex to customers via packages. Code coverage requirement for deployment. So to deploy code or package it for the lightning platform app exchange, at least 75% of Apex code must be covered by tests, and all those tests must pass. So it is the minimum requirement. But while you are writing any Apex test, so try to have at least 80 to 90% code coverage so that whenever your Apex code is changed, so it will be at least 75% because every time whenever Apex code changes, you need to change your Apex test class as well. In addition, each trigger must have some coverage. Even though code coverage is a requirement for deployment, don't write tests only to meet this requirement. Make sure to test the common use cases in your app, including positive and negative test cases and bulk and single record processing. So make sure through test classes you test both the positive and negative cases and also try to implement test classes for bulk testing. And if you want to know like how we can implement test classes and how it works in Salesforce, so you can just visit StudySalesforce.com there you will find all the pre-recorded videos. Important about test class. So calls to system.debug are not counted as part of Apex code coverage so that you need to remember. Test methods and test classes are not counted as part of Apex code limit. So no worries about writing long test class with more methods. Just to make sure that all your code branches are covered. Class can be deployed on 0% coverage as well, but that overall coverage of your production or after getting your code deployed should be 75% otherwise Salesforce won't let you deploy your code. So this is the syntax of test class. If you're creating any class and you want to convert it into test class, so you just need to write at the rate is test annotation before the class and before each method as well. Then at the rate is test and test method so at the rate test is test is the annotation and test method is the keyboard. So just prefer this at the rate is test annotation. Test dot start test and test dot stop test. So these are two important statement which we use in the methods which we implement in the Apex test. So the start test method marks the point in your test code when your test actually begins. Each test method is allowed to call this test method only once. Any code that executes after the call to start test and before stop test is assigned a new set of governor limits. The start test method does not refresh the context of the test. It adds a context to your test. So always remember if you want a new set of governor limit for each method of your test class. So you can enclose your code inside this start test and stop test methods. For example, if your class makes 98 as a girl queries before it calls start test and the first significant statement after start test is a DML statement. The program can now make an additional 100 queries one stop test is called. However, the program goes back into the original context and can only make two additional as a girl queries before reaching the limits of 100. So because of this start test and stop test, you will get additional 100 queries limit, right? So all asynchronous calls made after the start test method are collected by the system when the stop test is executed all asynchronous processes are run synchronously. Next question can be what is at the rate test setup. So use test setup methods, methods that are annotated with at the rate test setup, right? So to create test record once and then access them in every test method in the test class. So for example, if you are recreating data in your test class in different different methods. You can start off creating them again and again in each method. So you can create a common method that you can annotate with a great test setup annotation and whatever data you create in that method. So in other methods, you can just query the data and you can write your test methods. Test setup methods can be time saving when you need to create reference or prerequisite data for all test methods or a common set of records that all test methods operate on. If a test class contains a test setup method, the testing framework executes the test setup method first before any test method in the class. Further related to at the rate test setup only so records that are created in the test setup method are available to all test methods in the test class and are rolled back at the end of test class execution. So whatever data you create in the test setup method which is annotated with at the rate test setup. So in one method if you have varied the data and if you have done some changes. In another method, those changes will be rolled back and in the another method you will be having the fresh data. So last point says if a test method changes those records such as record field update or record deletion those changes are rolled back after each test method finishes execution. The next executing test method gets access to the original unmodified state of those reports. So that is why if you recreate data so instead of recreating them you can just use at the rate test setup annotation and how it is work how it works in Salesforce. So just visit study salesforce.com you will find a video and you can just understand common test utility or test data factory class. So similar to at the rate test setups like there we created common data in a class but in suppose that common data you want to use in multiple classes. So you can create a separate class for data creation and that class you can use in another test classes for testing. So that can be named as test utility utility or data factory or any other name as per your project requirement. So create test utility or data factory class to create test records once and then access them in test methods of any of the test class. This class can be time saving because when you need to write code for prerequisite data creation once the test methods those are available in different test classes. You can call methods defined in test utility or data factory class in test class as and when required. Now assert is also important in test classes so what is assert in test class it can be a good interview question. So while implementing test class in each test method we can validate the result to do so we can use assert in the code we need to make sure all asserts should pass. If any of the assert fails it means either assert is not written correctly or there is some errors in the code for that you are writing test method. So for example how to write assert so you can write system dot assert. So here first parameter will be Boolean condition and then message and another is assert equals which receives expected and actual as in parameter and third is a message. So here if both expected and actual matches so assert will pass if both doesn't match so it will fail. Now Apex class Apex test class best practices. So start test class with at the rate is this annotation and start test method with at the rate is this annotation as well methods of test class must be static and why name your test class as your original class plus test or trigger name plus test. So you can just append the test so that they should resemble same except that test word. Prepare your test data which needs to be used for test runs. Further always write test methods will with bulkify data either use at the rate test setup or util class. Use test dot start test and test dot stop test methods to make sure that the actual testing of your code happens with the fresh set of government limits. These methods help you to reset your government limits just before your actual code of testing gets executed. Use assert statements to test whether the actual code is executing correctly and giving the result as expected. Always try to test both positive and negative scenarios. So these were some best practices of Apex test class that you need to remember. Next we have at the rate is test here we can write see all data equals to true. So it annotates your test class or test method with to open up data access to records in your organization. So if you want to fetch the data that is available in your or under S objects. So you can write see all data equals to true. So the at the rate is test see all data equals to true annotation applies to data queries, but doesn't apply to record creation or changes including deletion. So you can just query the data but you can't change new and change records are still rolled back in Apex test even when using the annotation. If a test class is defined with the at the rateist test see all data equals to true annotation the annotation applies to all its test methods. The annotation applies if the test methods are defined with the at the rateist test annotation If a test class is not defined with the address test, see all data equals to true annotation, and any specific method is defined with address test, see all data equals to true annotation, then that specific method can access all data of the org, other methods cannot. Using the run as method, so it is also important, usually all Apex code runs in a system mode, where the permissions and record sharing of the current user aren't taken into account. The system method run as enables you to write test methods that change the user context to an existing user or a new user so that the user's record sharing is enforced. The run as method doesn't enforce user permission or field level permissions only record sharing. You can use run as only in the test methods. The original system context is started again after all run as test methods complete. The run as method ignores user license limit. You can create new users with the run as even if your organization has not additional user licenses. So this is the way how we can use it. So you just need to query the profile and then you need to create a user. So you need to initialize all required fields of the user object and your user will be created and then that newly created user you can use here in system.run as you. And whatever code you write inside these braces, so those code will be running as that newly created users context. So these are some Apex test class related interview questions and answers. So I hope these questions will help you. While giving any interview and if you want to learn these concepts and details or just visit study salesforce.com. Thank you.