You need to sign in to do that
Don't have an account?
How do I see what lines are not covered?
I have a simple trigger that works in the sandbox, does exactly what I want it to do. Cannot get code coverage above 40%.
I also do not know how to see what code is not covered. The test class below was pieced together from samples I found.
Any help would be appreciated!
Trigger:
trigger Pharmacy_Demo_Completed on Task (before insert){
for (Task T : trigger.new){
string TaskProfile = 'Implementation Director';
string TaskSubject = t.subject;
string TaskType = 'Send Contracts';
if (TaskSubject == 'Pharmacy Demo Completed'){
List <User> usr = [select Id from User where Profile.Name =:TaskProfile limit 1];
system.debug (Usr.size());
If (Usr.size() < 1){
system.debug ('No entries found for ');}
if (usr.size() > 0){
User u = [select Id ,name from User where Profile.Name =:TaskProfile limit 1];
t.ownerid = u.id;
t.type = TaskType;}
}
}
}
Test Class: (Saves without error)
@isTest
public class Taskusertest2 {
List<Task> insertedTasks = new List<Task>{};
static testMethod void myUnitTest() {
for(Integer i = 0; i < 100; i++)
{Task t = new Task();
t.IsRecurrence = FALSE;
t.sma__CreatedLocationVerified__c = FALSE;
t.IsReminderSet = FALSE;
t.MA_Clean_State__c = 'tx';
t.Subject = 'Testing';
t.Type = 'Research';
t.Priority = 'Normal';
t.Description = 'Task Class Test';
t.Status__c = 'Demo Scheduled';
t.Status = 'Completed';
insert t;}
List<Task> insertedTasks = [SELECT Description
FROM Task
WHERE Status = 'Demo Scheduled'];
{for(Task t : insertedTasks)
System.assertEquals(
'This Task is probably left over from testing. It should probably be deleted.',
t.Description);}
}}
Method 1: Go to Developer Console, select Test | New Run | <your test class> and run. Once completed, the test coverage is shown in the Overall Code Coverage pane; double click the test class. This displays the Apex code and you can see in red the lines that are not covered. (You may need to choose the 'All test xx%' submenu to see the red (uncovered lines))
Method2 - Use Eclipse IDE - run tests - results shows code coverage by line number uncovered
Go to ApexClasses -> Your Class - Beside the name of your class there is a column called Code Coverage. In that column your classes' code coverage is showing. If you click on that link then it will show what lines are not covered.
If this post is helpful please throw Kudos.If this post solves your problem kindly mark it as solution.
Thanks
Hi,
You can see the no of lines covered by cliking on the link that shows how much percentage is there for the class or trigger.
Otherwise, go to Setup>Developer Console, click on Tests.
There your trigger will show the percentage covered. Click on your trigger. Now you can see the lines covered by blue colored lines and Red colored lines are nor covered.
Now, if the trigger is written for event while inserting means you need to insert the dummy data in your test class and lines will get covered.
If trigger is meant to update means first inert dummy data with the criteria you mentioned in trigger, and then update some value for that criteria.
Hope this will help you...!
Michael L. Milner
Senior Business Intelligence Analyst / Salesforce Administrator
10100 Reunion Place, Suite 700, San Antonio, Texas 78216
o 210-587-3486 ext. 132 / f 210-576-0420
michael.milner@capturerx.com
[cid:image001.png@01CEB829.75FD0850]
[cid:image002.png@01CEB829.75FD0850] [cid:image003.png@01CEB829.75FD0850] [cid:image004.png@01CEB829.75FD0850] [cid:image005.png@01CEB829.75FD0850]
CaptureRx is a DBA under NEC Networks LLC. The information in this
email may be confidential and/or privileged. This email is intended
to be reviewed only by the individual or organization named above.
If you are not the intended recipient or an authorized representative
of the intended recipient, you are hereby notified that any review,
dissemination or copying of this email and its attachments, if any, and
any use or disclosure of the information contained herein, is prohibited.
If you have received this email in error, please immediately notify
the sender by email or telephone and permanently delete this email
from your system.
Michael L. Milner
Senior Business Intelligence Analyst / Salesforce Administrator
10100 Reunion Place, Suite 700, San Antonio, Texas 78216
o 210-587-3486 ext. 132 / f 210-576-0420
michael.milner@capturerx.com
[cid:image001.png@01CEB82B.6770E700]
[cid:image002.png@01CEB82B.6770E700] [cid:image003.png@01CEB82B.6770E700] [cid:image004.png@01CEB82B.6770E700] [cid:image005.png@01CEB82B.6770E700]
CaptureRx is a DBA under NEC Networks LLC. The information in this
email may be confidential and/or privileged. This email is intended
to be reviewed only by the individual or organization named above.
If you are not the intended recipient or an authorized representative
of the intended recipient, you are hereby notified that any review,
dissemination or copying of this email and its attachments, if any, and
any use or disclosure of the information contained herein, is prohibited.
If you have received this email in error, please immediately notify
the sender by email or telephone and permanently delete this email
from your system.
Appreciate it.
For the most part, a better strategy is just to design your code so you are certain your test classes will have 100% coverage. Then you can just move one to seeing if you tested all the possible condition values. There are some best practices that really help. The biggest the original poster missed, is ALWAYS write your trigger code in a class. Your trigger should need to do little more than invoke your class. If you need more that three lines of code in a trigger, you are probably not following best practices. Second, design your trigger classes to take Map's, and Lists, etc as parameters so they do not need to reference the Trigger object. That way your test class will not have to do DML operations to test your trigger class, just your 3 lines (or less) trigger. A third is to split your code into methods that take an parameters adequate to make it easy to unit test all conditions.
I tend to take things what step further. When it does not have a significant impact on performance, I try to make every condition step through every line of code. That way I can have one very simple test that will give me 100% coverage, and I can spend almost all my time working on what is most needed to make sure the code continues to work after future refactoring. Or better if you are doing test driven development, that your test will work once you implement the new functionality.
Thanks again.