각도로 어셈블리 시뮬레이션

Angular를 사용하는 프런트엔드 개발자입니까?만약 그렇다면, 코드가 예상대로 작동하고 있다는 것을 확신할 수 있도록 단원 테스트를 작성해야 합니다.
이 시리즈는 단원 테스트의 개념을 포함하고 각도 프로젝트에서 흔히 볼 수 있는 조작을 어떻게 테스트하는지 보여 줍니다.
첫 번째 문장에서 나는 세 가지 일을 완성하고 싶다.

왜 격리 테스트가 중요한지 알아보기

각도에서 의존 관계를 어떻게 해석하는지 알아보기

아날로그 구성 요소

이해

격리 테스트

여러 해 동안 내가 주의한 것은 많은 개발자들이 단원 테스트의 관건적인 개념인 고립 테스트를 이해하지 못했다는 것이다.
격리 테스트는 복잡하게 들리지만 사실은 간단한 개념이다.
격리 테스트는 테스트된 단원이 응용 프로그램의 다른 부분과 분리되어야 한다는 것을 의미한다.
우리가 Angular에서 단원 테스트를 토론할 때, 이것은 무엇을 의미합니까?
구성 요소, 서비스, 파이프 등 어떤 테스트를 하고 있든지 간에 모든 다른 의존 항목 (단원) 을 분리/시뮬레이션해야 합니다.
만약 당신이 단독으로 테스트를 하지 않는다면, 모호한 컨트롤러 오류 중에서 선별하여 테스트 실패의 원인을 찾아내려고 할 때, 당신은 결국 몇 시간 동안 머리가 아플 것이다.
아니면 좀 곤혹스러워요?읽기 유지;나는 곧 몇 가지 일을 분명히 할 것이다.

그렇다면 각도는 의존 관계를 어떻게 처리합니까?

어셈블리를 깊이 있게 시뮬레이션하기 전에 Angular가 의존 관계를 어떻게 해석하는지 알아야 합니다.Angular는 모듈을 통해 의존 관계를 해결합니다.
This is one of the best descriptive definitions I've found.

In Angular, a module is a mechanism to group components, directives, pipes and services that are related, in such a way that can be combined with other modules to create an application. An Angular application can be thought of as a puzzle where each piece (or each module) is needed to be able to see the full picture.

app.module.ts 파일을 엽니다.

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

NgModule에는 다음과 같은 몇 가지 속성이 있습니다.

declarations 수조는 응용 프로그램의 구성 요소, 명령어, 파이프를 열거하는 데 사용됩니다.Angular CLI를 사용하여 새 구성 요소, 명령 또는 파이핑을 생성할 때마다 자동으로 배치됩니다.

imports 어레이는 응용 프로그램의 다른 모듈을 열거하는 데 사용됩니다.

providers 수조는 서비스를 열거하는 데 사용되지만, 일반적으로 app.module.ts 파일에서 공급자 수조를 편집하지 않습니다.

모든 진열이 무엇을 맡고 있는지 기억해 보세요. 우리는 곧 돌아와서 이 문제를 토론할 것입니다.

문제

Angular CLI를 사용하여 새 프로젝트를 생성하면 기본적으로 AppComponent이 생성됩니다.
새로운 프로젝트에도 기본 테스트가 있습니다.테스트를 실행하면 다음과 같은 결과가 발생합니다.

NOTE: I have 'ChromeHeadless' enabled in my karma.config.js file.

출발점은 좋지만, 새로운 구성 요소와 서비스를 만들고 있다는 것을 곧 알게 될 것이다.
Angular CLI를 사용하여 웹 응용 프로그램에 내비게이션 표시줄을 표시하는 HeaderComponent이라는 새 구성 요소를 생성합니다.웹 응용 프로그램에 표시할 구성 요소 생성이 부족합니다.우리는 화면에 렌더링하기 위해 그것을 사용해야 한다.이를 위해 HeaderComponent의 AppComponent을 사용한다고 가정해 보자.

// app.component.html

<div>
   <app-header></app-header>
</div>
...

현재 AppComponent이 정상적으로 작동하기 위해서는 HeaderComponent을 렌더링해야 합니다.따라서 AppComponent은 HeaderComponent에 의존한다고 할 수 있다.
테스트의 측면에서 볼 때, 우리는 지금 문제가 하나 있다.
만약 우리가 npm test을 사용하여 프로젝트에서 테스트를 실행한다면, 우리는 약간의 실패한 테스트를 보게 될 것이다.

왜?
터미널의 출력을 보는 것은 우리에게 단서를 제공했다.AppComponent과 관련된 테스트 파일은 우리가 테스트를 격리하고 있다고 가정합니다.구성 요소 테스트를 실행하는 데 필요한 내용만 포함합니다.테스트 구성 요소의 템플릿 파일에 새로운 의존항 (HeaderComponent) 을 도입했기 때문에, 테스트 환경은 HeaderComponent에 대해 아무것도 모르기 때문에 불평하기 시작한다.app.component.spec.ts 파일을 엽니다.다음 코드와 HeaderComponent의 정의가 누락되었음을 주의하십시오.

describe('AppComponent', () => {
  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [
        AppComponent
      ],
    }).compileComponents();
  }));

....
{

Angular CLI를 사용하여 HeaderComponent을 생성하면 구성 요소를 자동으로 "declarations"그룹의 app.module.ts 파일에 가져오지만 테스트 파일의 구성 요소는 포함되지 않습니다. 위의 그림과 같습니다.app.component.spec.ts 파일은 HeaderComponent 수조에 declarations을 열거하지 않았기 때문에 이 의존 관계를 어떻게 만족시킬 수 있는지 모른다.

잘못된 "솔루션"

이제 테스트 실패의 원인을 알 수 있습니다. 첫 번째 반응은 HeaderComponent을 가져와 declarations 그룹에 포함시킬 수 있습니다. 아래와 같습니다.

beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [
        AppComponent,
        HeaderComponent
      ],
    }).compileComponents();
  }));

이렇게 하고 테스트를 실행하면 모든 테스트를 통과할 수 있다.

좋아요, 그렇죠?
응, 진짜가 아니야.HeaderComponent을 도입하여 테스트 환경은 현재 진정한 HeaderComponent을 사용하고 있습니다.이것은 고립 테스트의 규칙을 깨뜨렸다.만약 HeaderComponent 내부에 다른 구성 요소가 있거나 그 안에 서비스를 주입했다면, 이 모든 의존항은 현재 표시되고, 우리의 AppComponent 테스트 파일에서 사용될 것이다.부노 없어요.
우리는 어떻게 이 문제를 해결합니까?
어디 보자.

진정한 솔루션 - 비웃음

우리는 진정한 HeaderComponent을 사용하지 않고 HeaderComponent과 유사한 위조 클래스 (mock) 를 만들어서 테스트 환경에 제공할 수 있다.이것은 테스트 환경을 즐겁게 하고 구성 요소의 모양을 정의할 수 있으며 다른 의존항이나 봉인 논리가 필요하지 않습니다.이것은 테스트를 매우 간단하게 한다.
그렇다면, 우리는 어떻게 구성 요소를 모의합니까?
이것은 매우 간단하다.
테스트 파일의 맨 위에 @Component 장식기를 사용하고 새로운 아날로그 구성 요소 클래스를 정의합니다.

@Component({
  selector: 'app-header',
  template: ''
})
class MockHeaderComponent {}

다음 사항에 유의하십시오.

selector 속성의 값은 실제 HeaderComponent의 선택기와 일치합니다.이것은 반드시 실제 HeaderComponent 선택기와 일치해야 한다. 이것이 바로 테스트 환경이 의존성을 만족시키는 방식이다.

템플릿 속성은 필요하지만 빈 문자열로 유지할 수 있습니다.

현재 우리는 아날로그 구성 요소를 정의하여 TestBed.configureTestingModule으로 돌아가 MockHeaderComponent 클래스를 declarations 그룹에 포함시켰다.

TestBed.configureTestingModule({
      declarations: [
        AppComponent,
        MockHeaderComponent
      ],
    }).compileComponents();

현재, 만약 우리가 테스트를 실행한다면, 모든 것이 여전히 통과될 것이다.다른 점은 AppComponent이 현재 테스트에서 아날로그 클래스를 사용하고 있다는 점이다. 진정한 HeaderComponent이 아니라.
잘했어!

마지막 생각

Angular에서 구성 요소를 시뮬레이션하는 방법을 알았으니, 개발자가 단원 테스트를 할 때 직면하는 가장 흔히 볼 수 있는 문제 중 하나를 해결했습니다.
실제 기업 응용 프로그램에서 모든 구성 요소의 시뮬레이션을 프로젝트의 디렉터리로 이동하여 모든 테스트 파일이 필요한 시뮬레이션 구성 요소를 가져올 수 있도록 합니다.
나는 본고가 도움이 되고 격리 테스트의 신비한 베일을 벗기는 데 도움이 될 뿐만 아니라, 어떻게 Angular에서 구성 요소를 시뮬레이션하는지에도 도움이 되기를 바란다.
이 시리즈의 다음 부분에서, 나는 당신에게 어떻게 시뮬레이션 서비스를 보여 드리겠습니다. - 나의 시사통신을 구독해야 합니다. 그러면 당신은 그것을 놓치지 않을 것입니다!