Salesforce 통합 테스트를위한 팁 및 모범 사례

세일즈 포스 통합

Salesforce 테스트는 사용자 정의 된 Salesforce 통합 다른 엔터프라이즈 응용 프로그램과의 기능. 좋은 테스트는 계정에서 리드, 기회에서 보고서, 캠페인에서 연락처에 이르는 모든 Salesforce 모듈을 다룹니다. 모든 테스트의 경우와 마찬가지로 Salesforce 테스트를 수행하는 좋은 (효과적이고 효율적인) 방법과 나쁜 방법이 있습니다. 그렇다면 Salesforce 테스트 모범 사례는 무엇입니까?

  • 올바른 테스트 도구 사용 – Salesforce 테스트는 브라우저 또는 Eclipse 기반 환경에서 수행됩니다. 최신 브라우저와 Eclipse에는 모두 훌륭한 디버깅 도구가 있으며이를 테스트 클래스와 결합하여 매우 유용한 결과를 얻을 수 있습니다. 그러나 더 필요한 경우 Force.com의 Apex Interactive Debugger (또는 간단히 Apex)를 사용해야합니다. 크롬 확장 프로그램 인 Salesforce Lightning Inspector를 사용하여 특히 Salesforce Lightning을 테스트 할 수도 있습니다. Apex는 Force.com Java와 매우 유사한 플랫폼 독점 프로그래밍 언어. 이는 중괄호와 점 표기법 구문을 따르는 객체 지향적이고 대소 문자를 구분하지 않는 강력한 유형의 프로그래밍 언어입니다. Apex를 사용하여 대부분의 Force.com 프로세스 중에 Visualforce 페이지 사용자 지정 컨트롤러 또는 일정을 통한 사용자 지정 링크 및 단추, 업데이트, 삭제 및 레코드 삽입 이벤트 처리기를 포함하여 프로그래밍 된 기능을 실행할 수 있습니다.
  • 적절한 이름 지정 규칙 사용 – 테스트 작성을 시작하기 전에 테스트 방법의 적절한 이름을 지정하는 것은 매우 중요합니다. 테스트 방법 이름은 세 부분으로 구성되어야합니다. 이는 nameOfMethod (트리거 테스트시 삽입 / 업데이트 / 삭제 / 삭제 취소와 같은 테스트중인 개별 메서드의 이름, 연락처가 null인지 테스트하는 경우 null 연락처와 같이 유연한 TestPath에 대한 정보, 테스트시 유효 함)입니다. 긍정적 / 부정적 경로.
  • 100 % 보장 보장 – 표준 Salesforce 지시문은 단위 테스트가 코드의 75 %를 포함해야하며 (테스트 클래스, System.debug 및 테스트 메서드에 대한 호출 제외) Apex 코드를 배포하거나 AppExchange 앱을 패키징 할 수 없다는 것입니다. 이것은 표준 일 뿐이며 목표는 100 % 커버리지 여야합니다. 모든 긍정적 / 부정적 사례와 존재하지만 존재하지 않는 데이터를 테스트합니다. 코드 커버리지에 관한 다른 중요한 팁은 다음과 같습니다.
    • 테스트를 다시 실행할 때까지 Apex 코드가 업데이트 될 때 이러한 번호가 새로 고쳐지지 않으므로 코드 검사 번호를 새로 고치려면 테스트를 실행해야합니다.
    • 마지막 테스트 실행 이후 조직에 업데이트가있는 경우 코드 검사 번호가 잘못 될 위험이 있습니다. 올바른 추정치를 위해 테스트를 다시 실행하십시오.
    • 코드 커버리지 백분율에는 관리 패키지 테스트의 코드 커버리지가 포함되지 않습니다. 단, 이러한 테스트로 인해 트리거가 실행되는 경우는 예외입니다.
    • 적용 범위는 총 코드 라인 수에 따라 다릅니다. 코드 줄을 추가하거나 삭제하면 백분율에 영향을줍니다.
  • 클래스 및 컨트롤러의 테스트 케이스 – Salesforce 개발에서 대부분의 개발자는 각 기능에 대해 별도의 클래스와 컨트롤러 파일을 만듭니다. 이는 코딩을보다 체계적이고, 더 쉽고, 재사용 가능하고, 이식 할 수 있도록하기위한 것입니다. 그러나 이것이 더 쉽지만 더 효율적이지는 않다는 점에 유의해야합니다. 샌드 박스에서 프로덕션으로 마이그레이션 할 때 테스트 클래스를 놓치지 않기 때문에 테스트 코드가 원래 클래스와 컨트롤러 코드 자체에 있으면 이식성을 얻을 수 있습니다.
  • System.assert () 사용 – Apex에서 System.assert()는 조건을 확인하는 데 사용됩니다. 이는 특정 기능이 예상대로 메서드에 의해 수행되었는지 확인할 수 있기 때문에 중요한 기능입니다. 중요한 기능간에 System.assertEquals () 및 System.assertNotEquals ()를 사용하면 코드가 제대로 실행되었는지 확인하는 데 도움이 될뿐만 아니라 코드가 잘못되어도 데이터가 잘못 기록되지 않도록 할 수 있습니다.
  • 포괄적 인 테스트 – 테스트는 모든 것을 다루어야합니다. 기능 테스트, 부하 테스트, 보안 테스트 및 배포 테스트를 수행해야합니다.
  • 단위 테스트 – 개별 레코드가 정확하고 예상되는 결과를 생성하는지 확인하려면 단위 테스트가 있어야합니다. 전체 코드를 포괄하는 거대한 테스트를 사용하는 것이 좋은 생각처럼 보일 수 있지만 생성 된 결과는 디버그하기 더 어렵고 실패는 이해하기 더 어렵습니다. 단위 테스트는 테스트되는 기능의 작은 하위 집합을 포함해야합니다.
  • 대량 사례 테스트 – 좋은 테스트 코드 (트리거, 예외 또는 클래스)는 최대 수백 개의 레코드 (Apex의 경우 200)에 포함될 수 있습니다. 이를 활용하여 개별 레코드뿐만 아니라 대량 케이스도 테스트해야합니다.
  • 양성 테스트 – 예상되는 모든 순열을 통해 예상되는 동작이 발생하는지 테스트합니다. 테스트는 사용자가 양식을 올바르게 작성했는지 그리고 한도를 초과하지 않았는지 확인해야합니다.
  • 음성 테스트 – 부정적인 경우를 테스트하여 오류 메시지가 올바르게 생성되는지 확인하십시오. 이러한 부정적인 경우의 예로는 음수 금액을 지정할 수없고 미래 날짜를 추가 할 수 없습니다. 상황이 남을 때 올바른 처리가 모든 차이를 만들 수 있기 때문에 부정적인 테스트가 중요합니다.
  • 테스트 자동화 – 전통적으로 Salesforce 테스트는 수동이었습니다. 더 많은 이점을 제공하므로 자동화 된 테스트를 고려해야합니다. 여기에는 다음이 포함됩니다.
    • 수동 테스트는 테스트가 로봇이 아닌 사람에 의해 이루어지기 때문에 실수에 취약합니다. 로봇은 반복적 인 활동에 탁월하고 인간은 지루함, 집중력 및 일관성 감소, 코너를 자르는 경향으로 인해 실수를합니다.
    • 수동 테스트는 반복적이고 공식적이며 피곤합니다. 테스트 팀은 더 탐구적인 작업을 수행하는 것이 좋습니다.
  • 각 코드 로직 분기 실행 – 조건부 논리를 사용하는 경우 (삼항 연산자를 포함한 경우) 코드 논리의 각 분기를 실행해야합니다.
  • 메서드 호출에 유효하지 않은 유효한 입력 사용 – 메서드에 대한 호출은 유효하지 않은 입력과 유효한 입력을 모두 사용하여 이루어져야합니다.
  • 완전한 테스트 – 테스트가 성공적으로 완료되었는지 확인합니다. 오류가 예상되지 않는 한 예외가 발생하지 않아야합니다. 잡힌 모든 예외를 처리합니다. 잡는 것만으로는 충분하지 않습니다.
  • ORDER BY 키워드 사용 – 레코드가 예상 한 순서대로 반환되도록하려면 ORDER BY 키워드를 사용하십시오.
  • 레코드 ID가 순차적으로 배열된다고 가정하지 마십시오. 레코드 ID가 순차적으로 정렬되어 있다고 가정하는 일반적인 실수를 피하십시오. 동일한 요청으로 여러 레코드를 삽입하지 않는 한 ID는 오름차순이 아닙니다.
  • Test.startTest () 및 Test.stopTest () 호출 – Apex 단위 테스트를 실행하면 Salesforce에서 필수 인 75 % 이상의 코드 검사를 받게됩니다. 여전히 실행 중일 수있는 비동기 코드를 완료하려면 어설 션 전에 stopTest를 호출해야합니다. 다른 코드가 데이터를 변경할 수 있으므로 최종 결과에 대해 새로운 쿼리를 실행합니다. Test.startTest () 및 Test.stopTest ()를 사용하면 관리자 제한 내에서 테스트를 샌드 박스화할 수 있습니다. 이렇게하면 사용하는 설정 코드가 간섭하지 않고 거버너 한계를 둘러싼 거짓 부정 또는 긍정을 제공하지 않습니다. Test.stopTest ()는 또한 @future 호출이 테스트를 위해 완료되도록합니다.
  • 가독성 – 가독성은 단위 테스트에서 매우 중요합니다. 테스트 이름에는 취해야 할 특정 조치와 예상 결과가 포함되어야합니다. 방법은 설명적이고 짧아야합니다. 방법은 여러 테스트에서 재사용 할 수 있어야합니다.
  • startTest 전에 대규모 테스트 데이터 세트 구축 – 테스트가 서로 다른 샌드 박스 및 프로덕션 환경에서 실행되므로 startTest를 호출하기 전에 대규모 테스트 데이터 세트를 빌드하여 테스트에 전체 실행 제한이 있는지 확인하십시오. 기본적으로, 세일즈포스 깃허브 프로덕션 데이터에서 격리 된 테스트를 실행합니다. 프로필과 같은 시스템 데이터가 필요한 경우 해당 특정 환경에 맞는 것을 가져 오기 위해 쿼리하십시오.
  • 자신의 테스트 데이터 생성 – 사용하는 테스트 데이터는 테스트에서 생성되어야합니다. @testSetup 주석 및 TestUtils 클래스를 사용하여이 데이터를 생성하여 올바른 데이터가 있는지 확인하는 것뿐만 아니라 모든 테스트가 데이터 요구 사항없이 개발자 샌드 박스에서 실행되도록 할 수 있습니다.
  • 작동하지 않는 AKA null 작업 방지 – 많은 테스터가 no-op AKA null 연산을 사용합니다. 이것들은 아무것도하지 않는 쓸모없는 코드입니다. 이미 코드베이스에 있으므로 적용 비율에 추가됩니다.
  • 병렬 테스트 실행 – Salesforce 사용자 인터페이스 또는 개발자 콘솔에서 테스트를 시작하면 테스트가 병렬로 실행됩니다. 이것은 테스트 실행 시간을 단축하므로 중요한 기능입니다. 그러나 이로 인해 데이터 경합 문제가 발생할 수 있으며 이러한 상황이 발생할 수 있다고 의심되면 병렬 실행을 해제해야합니다. UNABLE_TO_LOCK_ROW 오류로 이어지는 데이터 경합 문제의 가장 일반적인 원인은 다음과 같습니다.
    • 테스트가 동일한 레코드를 동시에 업데이트하기위한 경우. 동일한 레코드의 업데이트는 일반적으로 테스트가 자체 데이터를 생성하지 않을 때 발생합니다.
    • 병렬로 실행되는 테스트에 교착 상태가 있고 일치하는 인덱스 필드 값이있는 레코드를 만들려고 할 때. 2 개의 실행중인 테스트가 데이터를 롤백하기 위해 대기 할 때 교착 상태가 발생합니다 (이는 2 개의 테스트가 서로 다른 순서로 동일한 고유 인덱스 필드 값을 갖는 입력 레코드를 테스트 할 때 발생 함).
    • 병렬 테스트 실행을 끄려면 설정으로 이동하여 Apex 테스트를 입력하고 Apex 테스트 실행 옵션 대화 상자로 이동하여 병렬 Apex 테스트 비활성화를 선택한 다음 확인을 클릭합니다.

병렬 Apex 테스트 비활성화

좋은 테스트를 수행하는 데 필요한 경험과 훈련을받을 수 있으므로 전문가를 고용하여 마음의 평화를 얻습니다. 전문가를 고용하면 핵심 비즈니스에 집중할 수 있습니다. 또한 작업을 위해 사내 팀이 필요하지 않으므로 비용을 절약 할 수 있습니다.

당신은 어떻게 생각하십니까?

이 사이트는 Akismet을 사용하여 스팸을 줄입니다. 댓글 데이터 처리 방법 알아보기.