i am trying to test my Controller .One doubt is in using Test.startTet and Test.stopTest().i am checking every method in separate unit test . for example

static testmethod void testEditApiSettings(){
    MirrorSettingsController ctrl = new MirrorSettingsController();   
System.assert(ctrl.editApiSettings,'Method perform to Show Insert view# Not able to set ');
static testmethod void testDeleteApiSettings(){
MirrorSettingsController ctrl = new MirrorSettingsController();
 GlassUserApiSettings__c userSettings =  GlassUserApiSettings__c.getValues(UserInfo.getUserId());
System.assert(userSettings== null ,'User settings are present ence Method don\'t delete Usetr Settings' );

so you can see i create ctrl every time in test.startTest() is this more appropriate or creating it before Test.startTest();

  1. there is a DML exception perhaps that cant come because DML limit is 100 and i am hardly using 2-3 in my controller. i write a function

    public PageReference deleteUserSettings(){
    delete userSettings;  
    userSettings = GlassUserApiSettings__c.getValues(Userinfo.getUserId());
    catch(System.DmlException e){System.debug(e); }
    return null;

    how to test this should i remove this try catch block (because exception is not expected)??How to test this catch block please guideline .

2 Answers 2


For this type of scenario prefer doing something that would create the exception and assert the exception in catch block of your test class.

1)You can try deleting this custom setting with certain user who has no permission to delete this custom setting and exception will be triggered due to permission issue .

2)Or may be try deleting something that dont exist at all in database ,means you have not formed test data

  • if i insert assert statement in catch will it do any thing with running in real app code if exception happened ??Need a little guideline Sep 25, 2013 at 5:47
  • means what assert function do if you are not Testing the code using the app ?? Sep 25, 2013 at 5:51
  • assert will be in test code .In test code when you run that method you will have it in try and catch.try{ method();}catch(exception e){system.assert(e.getmessage().contains('permission'))}.note all this done in test code only. Sep 25, 2013 at 5:52

This question illustrates a common problem with exception handling in Apex Code. Exceptions can be hard to generate on demand, meaning that many developers leave them out, but this causes a lousy user experience. The trick is to balance testing with user experience.

A skilled developer will write their logic such that 80% of their code will be testable in just a couple of tests. This is known as the 80-20 rule, which appears oftentimes in business logic, marketing logic, and even programming logic. Extensive error handling should be avoided, but the user experience should be preserved by judicious use of exception handling.

It is nearly impossible to achieve 100% code coverage for anything but the most trivial of code because the platform does not have a language expressive enough to permit 100% coverage. Even so, the larger problem at hand is trying to cover exception handling will cause large swathes of duplicate code. To understand this, consider a typical example:

try {
    // 20 lines of business logic
    insert record;
} catch(exception e) {
    // 2 lines of error handling logic

As this code snippet illustrates, a single test method might cover 21 of 23 lines of code, while a second method requires the same logic except for one small piece that allows the exception to occur. This means that the amount of test code was increased 100% in order to gain 9% code coverage. This is clearly inefficient. The larger the try block in relation to the catch block, the less efficient it becomes to bother testing the exception handling.

What exception handling is there for is two-fold: 1) to present a reasonable UI to the user so they don't get the Visualforce screen of death, and 2) to ensure that business logic is uniformly executed.

Note that I am not condoning skipping testing the exception handling "ad infinitum", but to delay it as long as possible, or if it is deemed impossible to cover, then simply making sure that the test method test the output of each method to make sure that no errors are masked. Masking an error with a try-catch block results in test methods that do not fail when they should have (regression testing).

Probably the most sane way of handling this situation is to simply report the error if not running a test, otherwise throw an assertion. I would put this within a utility class whose sole purpose is to show this message, which reduces the code footprint that has to be tested. That is really an advanced optimization that can be spared for later.

Without exception handling, if a user experiences an exception, they will be kicked out of the form they were working on, losing all their work they spent time entering into the system, and have to start over. This is a poor user experience that should be avoided at all cost. Exception handling is more important than code coverage.

Code coverage supplants exception handling by ensuring that logic bugs are avoided. It is true that code coverage is required, but you cannot sacrifice error handling in exchange for code coverage, because your application will perform worse. When writing test code, always cover the "true" paths first (the expected business logic), then cover the "false" paths later as time permits. Covering the "true" paths should almost always yield over 80% coverage.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .