Angular 템플릿 코드 범위 및 미래 보장 테스트를 위한 누락된 요소

TL;DR: Angular 테스트에 대해 AOT(Ahead-Of-Time) 컴파일을 켜서 정확한 템플릿 코드 적용 범위, 더 빠른 테스트 실행, 프로덕션 대칭 및 미래 보장을 얻으세요. 테스트합니다.

이 옵션은 이미 Vitest 사용자에게 제공되며 곧 Karma 및 Jest(실험용 빌더) 사용자에게도 제공될 예정입니다.

? JIT에 무슨 문제가 있나요?

Karma, Jest, Vitest 중 무엇을 사용하든 Angular 테스트에 JIT(Just-In-Time) 컴파일을 사용하고 있을 것입니다. 최근까지 JIT(Just-In-Time) 컴파일이 사용 가능한 유일한 옵션이었기 때문입니다.

문제는 JIT에 몇 가지 중요한 단점이 있다는 것입니다.

• 코드 범위가 정확하지 않습니다 템플릿이 고려되지 않습니다.
• 테스트에서 템플릿을 즉시 컴파일하므로 느립니다.
• Angular가 JIT 호환성의 한계에 도달했기 때문에 미래 보장형이 아닙니다. 설계상 일부 기능은 JIT로 구현하는 것이 불가능합니다.
• AOT를 사용하는 제작 환경과 대칭이 아닙니다.

⏰ 왜 지금인가?

Angular 8과 IVy 도입 이후 Angular 컴파일러는 템플릿을 명령어로 변환하기 시작했습니다. 다른 많은 이점 중에서도 코드 검사 도구가 이러한 지침을 템플릿에 매핑하고 그에 따라 코드 검사를 계산할 수 있다는 의미이기도 합니다.

이론적으로는 Angular 8부터 AOT로 테스트를 실행하여 코드 커버리지 생성이 가능했지만 Karma나 Jest에서는 해당 옵션을 사용할 수 없었습니다. 아날로그 팀이 Angular에 대한 Vitest 지원을 추가한 이후에만 테스트용 AOT를 활성화할 수 있었습니다.

2024년 11월 기준:

• Vitest는 AOT 컴파일을 지원하는 유일한 옵션입니다.
• AOT를 지원하기 위해 Karma 및 Jest Experimental Builder에 대한 공개 PR이 있습니다.

? AOT 테스트의 기타 이점

⚡️ 더 빠른 테스트 실행

JIT를 사용하든 AOT를 사용하든, 구성 요소는 어느 시점에 컴파일됩니다. 주요 차이점은 AOT를 사용하면 컴파일이 한 번 수행되어 캐시될 수 있는 반면, JIT를 사용하면 각 테스트 모듈에서 구성 요소를 다시 컴파일하게 될 수 있다는 것입니다.

즉, AOT를 사용하면 변환 단계가 조금 느려지더라도 전체 테스트 실행 시간은 더 빨라집니다. 제가 본 수치는 약 20% 더 빠른 실행을 나타내지만 이는 테스트 구조와 테스트 중인 시스템에 따라 크게 달라집니다.

? 생산-대칭

우리는 일반적으로 신뢰도를 높이기 위해 테스트가 프로덕션 환경에 최대한 대칭이기를 원합니다. 이는 테스트 속도, 테스트 대상 시스템의 크기, 예측 가능성과 같은 다른 속성과 균형을 이루기 때문에 어려운 경우가 많습니다.

AOT의 흥미로운 측면은 다른 속성을 손상시키지 않고 생산 대칭성을 향상시킨다는 것입니다. AOT를 사용하면 더 많은 자신감을 얻고 생산에 가까운 행동을 얻을 수 있습니다.

? 미래 지향적 테스트

더 중요한 것은 JIT가 한계에 도달하여 Angular의 부담이 되고 있다는 것입니다. 예를 들어 일부 Angular 기능은 JIT(예: 지연 가능한 뷰)에서 지원되지 않습니다. 선택기가 없는 구성 요소와 같은 Angular 로드맵의 다른 잠재적 기능은 아마 JIT와 함께 사용하는 것이 불가능할 것입니다.

실제로 Angular의 신호 입력(및 유사한 기능 API) 이후 JIT가 작동하려면 이미 최소한의 변환이 필요합니다.

AOT로 전환하면 테스트를 미래 지향적으로 만들고 모든 혁신의 혜택을 누릴 수 있으며 JIT의 미래에 대비할 수 있습니다.

? 단점

? 동적 구성 요소 구성은 피해야 합니다.

AOT를 켜면 동적 구성에 의존하는 일부 기술이 중단됩니다.

예를 들어 다음과 같은 사용법은 더 이상 작동하지 않습니다.

// ? This is broken with AOT.
const fixture = render(`<app-button></app-button>`, { imports: [Button] });

function render(template, { imports }) {
  @Component({
    template,
    imports,
  })
  class TestContainer {}

  return TestBed.createComponent(TestContainer);
}

그러나 AOT 컴파일을 우회하는 것은 여전히 ​​가능합니다 (⚠️ 현재로서는 ️⚠️):

function render(template, { imports }) {
  @Component({
    jit: true,
    template,
    imports,
  })
  class TestContainer {}

  return TestBed.createComponent(TestContainer);
}

제 조언은 이러한 구성을 가능한 한 피하고 필요할 때 테스트 전용 구성 요소를 만드는 것을 선호하라는 것입니다. 비록 좀 더 장황할 수도 있습니다. 앞으로 Angular 팀은 AOT와 호환되고 보일러플랫폼이 덜한 대안을 제공할 수 있습니다.

? 얕은 테스트가 더 어렵습니다.

얕은 테스트는 생산 대칭성이 낮기 때문에 주요 테스트 전략이 되어서는 안 되지만 여전히 도구 상자에 사용하면 유용한 기술입니다.

AOT에서는 현재 TestBed#overrideComponent를 사용하여 구성 요소 가져오기를 재정의하는 것이 불가능합니다.

해결 방법은 테스트 프레임워크의 API를 사용하여 모듈 수준에서 구성 요소의 종속성을 재정의하고 구성 요소를 해당 테스트 더블로 바꾸는 것입니다.

예를 들어 Vitest의 경우:

// app.cmp.spec.ts
vi.mock('./street-map.cmp', async () => {
  return {
    StreetMap: await import('./street-map-fake.cmp').then(
      (m) => m.StreetMapFake
    ),
  };
});

// street-map-fake.cmp.ts
@Component({
  selector: 'app-street-map',
  template: 'Fake Street Map',
})
class StreetMapFake implements StreetMap {
  // ...
}

이 임시 해결 방법은 AOT와 호환되지만 비용이 발생합니다.

• 가독성이 낮고 장황합니다.
• 모듈 수준에서 "모의"(또는 테스트 더블 제공)는 덜 세부적이고 예측 가능성이 낮습니다.
• 사용 중인 테스트 프레임워크와 긴밀하게 결합되어 있습니다.

지금으로서는 TestBed#overrideComponent가 AOT를 지원하거나 Angular 팀이 더 나은 대안을 제공할 때까지 얕은 테스트에 JIT를 사용하는 것이 좋습니다. *.jit.spec.ts와 같은 특정 패턴과 일치하는 테스트에 JIT를 사용하는 얕은 테스트에 대한 별도의 구성을 사용하면 이를 달성할 수 있습니다.

??‍? AOT와 함께 Vitest를 사용해 보세요

1. 비테스트 설정

• Angular CLI 사용자의 경우 Analog의 회로도를 사용하세요.
• Nx 사용자의 경우 애플리케이션이나 라이브러리 생성 시 vitest 옵션을 선택하세요(Nx 20.1.0부터 사용 가능).

2. AOT 활성화

vite.config.js 파일을 찾고 Angular의 플러그인 jit 옵션을 false로 설정하여 AOT를 활성화합니다.

// ? This is broken with AOT.
const fixture = render(`<app-button></app-button>`, { imports: [Button] });

function render(template, { imports }) {
  @Component({
    template,
    imports,
  })
  class TestContainer {}

  return TestBed.createComponent(TestContainer);
}

? 코드 적용 범위 구성

코드 적용을 위해 이스탄불이나 기본 v8을 사용할 수 있는 옵션이 있습니다. 어떤 이유로 v8을 사용할 때 아직 조사 중인 Vitest 커버리지 재매핑이 실패합니다. 해결책은 대신 이스탄불을 사용하는 것입니다.

1. @vitest/coverage-istanbul 설치

Vitest의 주요 버전
과 일치하는 Vitest Istanbul 버전을 설치하세요.

function render(template, { imports }) {
  @Component({
    jit: true,
    template,
    imports,
  })
  class TestContainer {}

  return TestBed.createComponent(TestContainer);
}

2. 이스탄불을 보험 제공자로 선택하세요

이스탄불을 사용하여 적용 범위를 활성화하려면 vite.config.mts를 업데이트하세요.

// app.cmp.spec.ts
vi.mock('./street-map.cmp', async () => {
  return {
    StreetMap: await import('./street-map-fake.cmp').then(
      (m) => m.StreetMapFake
    ),
  };
});

// street-map-fake.cmp.ts
@Component({
  selector: 'app-street-map',
  template: 'Fake Street Map',
})
class StreetMapFake implements StreetMap {
  // ...
}

? 실제로 시청해 보세요

이제 테스트를 실행할 수 있습니다.

export default defineConfig({
  ...
  plugins: [
    angular({ jit: false }),
    ...
  ],
  ...
});

그런 다음 커버리지 아이콘을 클릭하고 템플릿의 코드 커버리지를 살펴보세요. ?

(취재 보고서는 취재 폴더에서도 확인하실 수 있습니다)

컴파일러에서 생성된 명령을 기반으로 적용 범위가 계산됩니다. 이는 다음을 의미합니다.

구조적 지시문에도 적용됩니다.

자, 어떨까요!?

인라인 템플릿에도 적용 범위가 적용됩니다! ?

☢️ 코드 적용 함정에 주의하세요

코드 적용은 유용한 도구이기는 하지만 현명하게 사용해야 합니다. 엄격한 목표가 아닌 지표로 삼으세요.

관찰된 통계적 규칙성은 제어 목적으로 압력이 가해지면 붕괴되는 경향이 있습니다.

-- 찰스 굿하트

즉, 측정값이 목표가 되면 더 이상 좋은 측정값이 아닙니다.

가장 단순한 지표가 종종 가장 오해를 불러일으킬 수 있다는 점을 덧붙이고 싶습니다.

? 다음은 무엇입니까?

Karma 사용자는 곧 간단한 플래그를 사용하여 AOT를 활성화할 수 있게 됩니다.

Jest 사용자에게는 세 가지 옵션이 있습니다.

• 권장: Vitest로 마이그레이션하세요. (? 곧 가장 원활한 마이그레이션 경로를 공유할 예정이니 계속 지켜봐 주시기 바랍니다)
• AOT와 함께 실험용 빌더를 사용하세요.
• jest-preset-angular AOT 지원을 기다리세요.

Vitest 사용자는 지금 바로 AOT의 혜택을 누릴 수 있습니다. ?

? 추가 리소스

• ? 데모 레포
• ? AOT(Angular AOT) 컴파일러 문서
• ? 비테스트 문서
• ? Vitest의 Analog 문서

??‍? 실용적인 각도 테스트 비디오 강좌가 출시되었습니다!

리팩터링할 때마다 중단되는 버그나 유지 관리가 많이 필요한 테스트에 지쳤다면 제 비디오 과정인 Pragmatic Angular Testing이 도움이 될 것입니다!

Angular 앱을 안정적이고 유지 관리 가능하게 유지하기 위한 실용적이고 신뢰할 수 있는 테스트 전략을 알아보세요. (한시적으로 50% 할인!)

위 내용은 Angular 템플릿 코드 범위 및 미래 보장 테스트를 위한 누락된 요소의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!