0

Edit Sept 28th 2016

Thank you all for the feedback! I have a lot of reading to do and I will be marking this as answered.

Please see...

Customer Community User (Non-Plus) Sharing Set Access not applying when Creating Case

...as it is tangentally related to this Test Class & Trigger. Assistance there will be super appreciated!

Cheers!

Original Post

Trying to learn Apex and don't understand why this test class won't produce code coverage. The trigger successfully fires on a Case insertion.

Is this test class successfully inserting a case?? Is the schema code written correctly to decipher and insert a record type ID based on its name? (DeveloperName and Name is the same in this context)

@isTest
public class TestCaseAuto {
static testMethod void insertCase() {
    Case TestCase = new Case();
    TestCase.AccountId = '00129000005u8V0';
    TestCase.RecordTypeID = Schema.SObjectType.Case.RecordTypeInfosByName.get('Implementation').RecordTypeId;
    TestCase.Status = 'New';
    TestCase.Origin = 'Phone';
    TestCase.Ticket_Reason__c = 'IVR';
    insert TestCase;
    }
} 

All feedback is welcome, thanks!

  • Always wrap dml in try-catch block so you can capture the errors and see what's going on. – Kevin P Sep 27 '16 at 18:07
  • 3
    Also, A test without an Assert is just a waste of time. – Kevin P Sep 27 '16 at 18:11
  • 1
    One more suggestion here is Not to use Hard Coded Ids. Example, AccountId in above Test Class. Instead insert Account record first and use it as a reference. To get the accurate coverage, write a test class which will cover all scenarios in trigger code. – Devendra Sep 27 '16 at 18:24
  • 1
    @Kevin I strongly disagree that try/catch is appropriate in a test context, usually it leads to swallowed errors that are harder to hunt down. Devendra beat me to the punch but those suggestions are really important to consider. Your test does not see organization data by default, and you should not write data-dependent tests even if it is technically an option. – Adrian Larson Sep 27 '16 at 18:25
  • 1
    Thank you Morgan for the insights! I'm finding trailhead lessons aren't doing the job for the plain english brass tacks knowledge that facilitates understanding. – Sovereignty Sep 27 '16 at 20:49
3

You might gain some benefit from reading through the answers on a question I posed some time ago: Why Are Data Silos Important in Unit Tests?

The question of why you should not use hard-coded Ids is moot if you understand why you should create your own test data in the first place. Regardless, you should probably also read Best Practice: Avoid Hardcoding IDs. You will never have the same test pass in a developer sandbox and production at the same time if you use hard-coded Ids.

Also, you should thoroughly read How to Write Good Unit Tests. Here is an important passage for you to understand (emphasis mine):

Verify the results are correct

Verifying that your code works as you expect it to work is the most important part of unit testing. It’s also one of the things that Force.com developers commonly neglect. Unit tests that do not verify the results of the code aren’t true unit tests. They are commonly referred to as smoke tests, which aren’t nearly as effective or informative as true unit tests.

A good way to tell if unit tests are properly verifying results is to look for liberal use of the System.assert() methods. If there aren’t any System.assert() method calls, then the tests aren’t verifying results properly. And, no, System.assert(true); doesn’t count.

  • Thanks much Adrian, I'll be sure to look into all of those! – Sovereignty Sep 27 '16 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.