[Salesforce] Debug에 관해

Exception (예외)

어떤 오류가 났는 지, 어떤 오류 유형인 지, 오류가 발생한 시기의 스크립트 또는 프로그램의 상태에 대한 정보를 기록하는 클래스로, 메서드 내에서 오류 발생 시 Apex Engine으로 이동하는 Exception을 생성하고 발송한다.

try {
	update positions;
} catch (Ssystem.DmlException e) {
	System.debug('DML exception: ' + e.getDmlMessage(0));
} finally {
	posisitions.clear();
}

throw, try, catch, finally 키워드를 통해 오류를 제어할 수 있다. try는 Exception이 발생할 수 있는 구간을 묶는 용도로, 오류가 발생할 수 있는 코드 블록을 try 키워드로 감싸면 해당 코드 블록에서 오류가 발생 할 경우 Exception이 발생하여 catch 키워드 코드 블록으로 이동시킨다. catch는 Exception에 대한 처리를 개발자가 설정할 수 있는 구간이다. finally는 실행 성공 혹은 오류 발생 여부에 관계 없이 try 블록 실행 후에 무조건 실행하고자 하는 코드를 설정할 수 있다.

시스템 정의 Exception 클래스

표준 Exception을 의미하고 오류를 확인하기 위한 메서드를 포함한다. 범위에서 벗어난 인덱스에 접근 하려는 경우 ListException이 발생하며. 레코드 필수 필드가 누락된 경우 DmlException이 발생한다. 그 외에도 많은 Exception 유형이 존재한다.

https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_classes_exception_methods.htm

Exception Class and Built-In Exceptions | Apex Reference Guide | Salesforce Developers

getMessage() 메서드

사용자 인터페이스에서 사용자에게 표시되는 오류 메시지를 반환

 

getTypeName() 메서드

발생한 Exception의 유형을 반환

 

initCause(sObject Exception) 메서드

Exception의 원인을 설정하는 메서드

 

getCause() 메서드

Exception의 원인을 Exception 개체로 반환

 

사용자 정의 Exception 클래스

Exception 클래스를 상속받아 만드는 고유한 Exception 클래스로, Exception 처리 시 수행하는 동작 유형을 더 많이 제어해야 할 때 유용하다. 클래스명은 항상 Exception으로 끝나야 하며, catch-all 유형의 클래스이다.

public class MyCustomException extends Exception {}
sObject sobject = new sObject(Field = 'Sample Name');

try {
	insert sobject;
} catch (DMLException e) {
	throw new MyCustomException('Could not create a contact ', e);
} finally {
	System.debug('Tried to create a contact');
}

Exception 클래스를 확장해야 하며, 클래스명은 Exception으로 마무리 되어야 한다. (1행)

throw 이벤트를 발생하기 전, 사용자 정의 Exception 클래스에 대한 인스턴스를 생성해야한다. (7행)

---

디버깅

코드의 결함, 또는 오류 수를 찾아서 줄이는 프로세스 과정으로, Apex class 디버그는 Debug Log 및 익명 블록(Anonymous Blocks)을 통해 디버깅을 진행한다.

로그

기능 간의 상호 작용과 관련된 런타임 기능 문제를 식별하는데 도움이 된다. 코드를 실행하기 전에 출력을 추적하도록 디버그 로그를 요청할 수 있다. 시스템 로그는 프로젝트에서 발생하는 오류 및 시스템 프로세스를 기록한다. 시스템 로그를 사용하면 문제를 추적하거나 다른 선언적 기능을 사용하여 올바른 처리를 확인 할 수 있으며, 이에 따른 연쇄적인 오류를 해결할 수 있다. 시스템 로그는 로그 당 2MB, 조직 당 50MB로 제한된다.

로그 필터

디버그 로그에 반환되는 정보 유형으로, 시스템 로그에서 보는 메시지에 대한 대분류로 식별 가능하다.

Database

System.debug 메서드, DML 문, 인라인 SOQL, sObject 검색 언어 또는 SOSL 쿼리 호출에 의해 생성 된 로그 메시지

Workflow

워크플로 규칙, 할당, 자동 응답 규칙, 에스컬레이션 규칙 및 승인 프로세스에 대한 정보가 포함된다. 

Validation

유효성 검사 규칙에 대한 정보가 포함된다.

Callout

서버가 외부 웹서비스에서 보내고 받는 Request/Response XML이 포함된다.

웹 서비스 API 호출 사용과 관련된 문제를 해결할 때 유용하다.

Apex Code

System.debug 메서드, DML 문, 인라인 SOQL 및 SOSL 쿼리, 트리거의 시작 및 완료, 사용된 총 리소스와 같은 Apex 스크립트에 대한 모든 테스트의 시작 및 완료 정보를 포함한다.

Apex Profiling

가장 많은 리소스를 사용하는 SOQL문, Apex 메서드 호출 수, 메서드 호출 처리 시간과 같은 누적 프로파일링 정보를 포함한다.

Visualforce

Visualforce 화면에서 보이는 필드, 이벤트에 관한 정보를 포함한다.

System

System 메서드 호출에 대한 정보를 포함한다.

---

시스템 로그 수준

로그를 통해 개발자는 메시지를 보고자 하는 수준을 지정할 수 있다. 시스템 로그에는 디버그 로그에 반환되는 정보의 양을 지정할 수 있으며, Apex 모니터링에만 적용된다.

 

ERROR, WARN, INFO

오류, 경고 및 정보 메시지

DEBUG

System.debug 메서드 호출로 생성된 메시지 등 디버그 하위 수준의 메시지

FINE, FINER

System.debug 메서드, DML 문, 인라인 SOQL 또는 SOSL 쿼리에 대한 호출로 생성된 모든 로그 메시지

모든 사용자 정의 메서드의 시작 및 종료 메시지

FINEST

FINE 또는 FINER 로그 수준에서 생성된 모든 메시지와 더불어 변수 선언문, 루프 제어, 발생된 예외, 정적 및 클래스 초기화 코드, 공유 컨텍스트 변경 사항 등의 메시지를 포함한다.

 

디버그 로그 필터

디버그 로그에서 원치 않는 정보를 필터링 하고, 필요한 정보만 선별하여 확인 가능하며, 개별 클래스 및 트리거에 대한 로그 수준을 지정하도록 선택할 수 있다.

---

Developer Console

개발자 콘솔을 통해 Apex 스크립트를 작성하고, 실행할 수 있으며 코드가 성공적으로 실행되면 해당 코드에서 발생한 모든 작업에 대한 자세한 정보가 실행 로그에 기록된다. 최상위 작업부터 시작된 디버그 로그와 관련된 정보를 표시하는 트리 구조로 나뉘어진다.

실행 트리, 성능 트리, 소스 트리, 변수 트리, 실행 단위 트리, 제한 트리, 타임라인 트리 등으로 구성된다.

---

익명 블록

메타 데이터에 저장되지 않지만 동적으로 컴파일 및 실행되는 Apex 스크립트로, 익명 블록 컴파일 반환 결과에는 발생하는 오류를 포함하여 컴파일 실행 단계에 대한 상태 정보가 포함되고, 결과는 데이터베이스에 기록된다. 익명 블록을 통해 개발자는 Apex 클래스를 평가하고 런타임에 동적으로 변경되는 스크립트를 작성할 수 있다.

익명 블록은 static 키워드를 포함할 수 없다.

 

익명 블록은 executeAnonymous() 웹 서비스 API 호출, Developer Console, Force.com 플랫폼을 탑재한 IDE를 통해 실행할 수 있다.

 

테스트 전략에 대해

코드 테스트는 안정적이고 신뢰성 있는 서비스를 보장하는 중요한 활동으로, Salesforce에서는 이를 위한 Apex 코드 내 단위 테스트를 만들고 실행하는 과정을 지원한다.

 

Apex는 단위 테스트 메서드의 생성과 실행을 지원하며, 단위 테스트 메서드는 특정 코드가 예상대로 실행되는지 확인하는 Apex 메서드이다. 인수를 사용하지 않으며, 테스트에서 DML 작업이 실행 되더라도 데이터베이스에 이를 커밋하지는 않는다.

@isTest
public class myBusinessLoginClass_Test {
	private static testMethod void myBusinessLogicTest() {
    	// Code Block..
    }
}

@isTest
public class myBusinessLoginClass_Test {
	@isTest
    private static void myBusinessLogicTest() {
    	// Code Block..
    }
}

단위 테스트를 실행하기 위해서는 @isTest 어노테이션을 설정한 클래스 또는 메서드가 필요하며, 해당 메서드에 testMethod 속성을 부여하거나 해당 클래스 또는 메서드에 @isTest 어노테이션을 설정한다.

 

단위 테스트 진행 시 Governor Limit(가비나 제한)을 준수해야하며, 이를 위해 testMethod, startTest, stopTest 메서드를 사용할 수 있다. 단위 테스트 메서드는 각 testMethod 내 한 번만 호출할 수 있고, 각각을 개별로 사용할 수 없다. startMethod는 실제 메서드를 테스트 하기 전에 삽입해야 하며, startTest 메서드 이후의 다음 문장에서 stopTest 메서드까지 시스템은 분석을 위한 별도의 가비나 제한 집합을 추적한다.

 

runTests 메서드를 사용해 API 호출을 통한 단위 테스트를 실행할 수 있다. compileClasses 및 compileTriggers 메서드는 모든 테스트 혹은 특정 네임 스페이스 내 코드의 구문과 참조가 올바른지 확인하기 위해 사용할 수 있다.

 

단위 테스트는 선택 사항이 아닌 필수 사항으로 진행하는 것이 옳으며, Apex 스크립트의 75% 이상을 다루어야 하고 모든 트리거에는 테스트 범위가 1줄 이상 존재해야 한다. 또한, Exception을 발생시키지 않고 성공적으로 완료되어야하며, System.assert() 메서드를 사용해 단위 테스트의 예상 결과를 확인할 수 있어야 한다.

 

System.runAs() 메서드를 사용하여 레코드 공유, 데이터 액세스 가능성을 테스트 할 수도 있다. 테스트를 진행할 때에는 유효한 입력과 잘못된 입력을 모두 사용해 메서드를 호출하는 것이 적절하며, 레코드가 예상된 순서로 반환되도록 하기 위해서는 DML 문에 Order By 키워드를 사용하여 반환받아야 한다. 코드의 효율성을 테스트 하기 위해서는 200개 이상의 테스트 레코드를 만들어 진행한다.