JavaScript 구성 요소 둘러보기: 구성 요소 테스트

이번 호에서는 컴포넌트의 상태와 작동 모드가 예상한 대로인지 확인하는 JavaScript 테스트에 대해 다루겠습니다. 테스트 케이스를 쉽게 작성할 수 있는 테스트 방법도 소개하겠습니다. 여기서 언급하는 테스트는 물론 소프트웨어 품질 보증(QA)의 중요한 부분인 자동화된 테스트 방법을 사용하는 것입니다. 이 기사 시리즈에서 소개된 스마트 대기열에 관한 한 테스트 목표는 다음과 같습니다.

• Task 객체 생성 : 코드의 두 번째 단계에서는 다양한 생성 방법을 제공하며, 생성 후 객체의 상태를 테스트하는 데 필요합니다.
• 대기열 내의 작업 실행 순서 : 실행 순서를 변경하는 두 가지 방법, 즉 우선 순위와 종속성 구성을 제공하며 다양한 구성이 순서에 미치는 영향도 테스트해야 합니다.

첫 번째 목표는 생성 후 객체의 속성이 예상한 대로인지 확인하는 것입니다. 우리는 "기대에 부응하는 것"을 여러 번 언급했으며 Assert는 이를 위해 설계되었습니다. 간단히 말해서, 어설션은 테스트된 표현식의 결과가 "true"인지 확인하는 것입니다. 그렇지 않으면 어떤 방식으로든 테스터에게 알리고 어설션이 실패한 테스트 케이스를 찾는 데 도움을 줍니다.

두 번째 목표는 조금 더 복잡합니다. 컴포넌트 코딩 및 구현 중에 정렬된 큐(_sorted)를 클로저에 숨기므로 외부에서 접근할 수 없습니다. 고려해야 할 두 가지 방법이 있습니다: (1) 코드의 테스트 가능성을 높이기 위해 코드를 리팩토링하는 방법도 두 가지 있습니다. (a) 디버그 스위치를 설정하고 켜져 있을 때 _sorted를 외부에 노출합니다. 독립 파일을 추가하고 빌드 방식으로 코드를 연결하여 최종적으로 테스트 버전을 생성합니다. (2) 프로세스가 아닌 동작의 결과를 테스트합니다. 전자의 방법은 본질적으로 구성 요소의 런타임 상태를 자세히 살펴보는 반면, 이 방법은 구성 요소의 실행 결과만 확인합니다. 이번 호에서는 후자의 테스트 방법을 사용하며, 첫 번째 테스트 방법은 관심 있는 독자들이 연습해 볼 수 있도록 남겨둡니다 :)

나는 개인적으로 첫 번째 방법에 동의하지 않는다는 점에 유의해야 합니다. 이유는 무엇입니까? 먼저 이 작업 대기열의 디자인 개념에 대해 이야기하겠습니다.

• 이는 "요청 시" 작업 실행 순서를 조정하는 역할만 담당하고 작업의 개별 세부 사항에는 주의를 기울이지 않는 대기열일 뿐입니다. 즉, 작업별 행동이나 성과에 신경 쓰지 않고 전반적인 작업에 대해 작동합니다.
• 이는 보안 대기열입니다. 사용자(첫 번째 문제에서 언급된 "고객")는 작업 정보가 다른 고객에게 공개될 염려 없이 대기열에 작업을 추가할 수 있습니다. 구현 코드의 두 번째 단계에는 SmartQueue.Queue = [[], [], []]가 포함되어 있으므로 대기열 항목에 외부적으로 액세스할 수 있습니다. 이 코드는 소개용으로만 사용되며 보안 제어를 위해 SmartQueue.Queue =를 안전하게 제거할 수 있습니다.

출처: 알리페이 UED