Angular-Tutorial

"/> Angular-Tutorial

">

Heim  >  Artikel  >  Web-Frontend  >  Einführung in Angular-Unit-Tests mit Jasmine

Einführung in Angular-Unit-Tests mit Jasmine

青灯夜游
青灯夜游nach vorne
2020-08-22 11:23:262779Durchsuche

In diesem Artikel erfahren Sie, wie Sie Jasmine für Angular-Unit-Tests verwenden. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.

Einführung in Angular-Unit-Tests mit Jasmine

Das Folgende habe ich unter der Annahme erstellt, dass diejenigen, die selten oder gar keine Unit-Tests geschrieben haben, daher viele konzeptionelle Probleme in der Landessprache erklären können und sie auch in Kombination mit Jasmines entsprechenden Methoden erklären werden.

1. Konzept

Test Suite

Test Suite, selbst eine einfache Klasse, wird mehrere Testfälle haben, daher wird die Sammlung dieser Testfälle unter einer Kategorie Test Suite genannt.

In Jasmine wird es durch die globale Funktion describe dargestellt. Der erste Zeichenfolgenparameter wird zur Darstellung des Namens oder Titels der Suite verwendet, und der zweite Methodenparameter dient zur Implementierung des Suite-Codes.

describe('test suite name', () => {
});

Specs

Eine Specs entspricht einem Testfall, also dem spezifischen Codekörper, den wir zum Testen implementieren.

Jasmine verwendet zur Darstellung die globale Funktion it, ähnlich wie describe, mit zwei Parametern: Zeichenfolge und Methode.

Jede Spezifikation enthält mehrere Erwartungen zum Testen des zu testenden Codes. Solange ein Erwartungsergebnis false ist, bedeutet dies, dass sich der Testfall in einem fehlgeschlagenen Zustand befindet.

describe('demo test', () => {
    const VALUE = true;
    it('should be true', () => {
        expect(VALUE).toBe(VALUE);
    })
});

Erwartungen

Behauptungen, die durch expect globale Funktionen dargestellt werden, erhalten nur einen Repräsentanten des zu testenden tatsächlichen Werts und müssen mit einem Matcher abgeglichen werden, der den Erwartungswert darstellt.

2. Häufig verwendete Methoden

Matchers

Übereinstimmungsvorgänge durchführen, zwischen tatsächlichen Werten und erwarteten Werten vergleichen und Jasmine über die Ergebnisse benachrichtigen. Schließlich bestimmt Jasmine, ob diese Spezifikation erfolgreich ist oder scheitert.

Jasmine bietet eine sehr umfangreiche API, einige häufig verwendete Matcher:

  • toBe() entspricht ===
  • toNotBe() entspricht !==
  • toBeDefined() entspricht !== undefined
  • toBeUndefined() entspricht === undefined
  • toBeNull() Das Gleiche wie === null
  • toBeTruthy() entspricht !!obj
  • toBeFalsy() entspricht !obj
  • toBeLessThan() entspricht dbcd406f3a28d00dd5855178b820f0c7
  • toEqual() Äquivalent to ==
  • toNotEqual() ist äquivalent zu !=
  • toContain() ist äquivalent zu indexOf
  • toBeCloseTo() definiert die Genauigkeit beim Vergleich numerischer Werte, wobei zuerst gerundet und dann verglichen wird.
  • toHaveBeenCalled() prüft, ob die Funktion aufgerufen wurde
  • toHaveBeenCalledWith() prüft, ob der eingehende Parameter als Parameter aufgerufen wurde
  • toMatch() ist äquivalent zu new RegExp().test()
  • toNotMatch() ist äquivalent zu !new RegExp().test()
  • toThrow( ) prüft, ob die Funktion einen Fehler auslöst

und ob diese APIs zuvor not verwendet wurden, um eine negative Wertbeurteilung anzuzeigen.

expect(true).not.toBe(false);

Diese Matcher können fast unseren täglichen Bedarf decken. Natürlich können Sie Ihren eigenen Matcher auch an spezielle Bedürfnisse anpassen.

Setup und Teardown

Ein leistungsfähiger Testcode ist sehr wichtig, damit wir diese wiederholten Setup- und Teardown-Codes in die entsprechenden beforeEach und afterEach globalen Funktionen einfügen können.

beforeEach bedeutet, bevor jede Spezifikation ausgeführt wird und umgekehrt.

describe('demo test', () => {
    let val: number = 0;
    beforeEach(() => {
        val = 1;
    });
    it('should be true', () => {
        expect(val).toBe(1);
    });
    it('should be false', () => {
        expect(val).not.toBe(0);
    });
});

Datenfreigabe

Wie im obigen Beispiel können wir die entsprechenden Variablen am Anfang jeder Testdatei definieren, describe, sodass jeder it sie intern teilen kann.

Natürlich wird jeder Spec-Ausführungszyklus auch von einem leeren this-Objekt begleitet, bis es nach Ende der Spec-Ausführung gelöscht wird. Daten können auch mit this geteilt werden.

Verschachtelter Code

Wenn wir eine Komponente testen, hat die Komponente manchmal unterschiedliche Zustände, um unterschiedliche Ergebnisse zu zeigen. Zu diesem Zeitpunkt erscheint die Verwendung nur eines describe zu elegant.

Durch die Verschachtelung describe sehen der Testcode und der Testbericht daher schöner aus.

describe('AppComponent', () => {
    describe('Show User', () => {
        it('should be show panel.', () => {});
        it('should be show avatar.', () => {});
    });
    describe('Hidden User', () => { 
        it('should be hidden panel.', () => {});
    });
});

Überspringen Sie den Testcodeblock

Die Anforderungen sind immer halbherzig, aber der Testcode, der schließlich geschrieben wurde, sollte gelöscht werden? Nein...

Suites und Specs können die globalen Funktionen xdescribe bzw. xit verwenden, um diese Testcodeblöcke zu überspringen.

3. Arbeiten Sie mit dem Angular-Werkzeugset zusammen

Spy

Angular的自定义事件实在太普遍了,但为了测试这些自定义事件,因此监控事件是否正常被调用是非常重要。好在,Spy 可以用于监测函数是否被调用,这简直就是我们的好伙伴。

以下示例暂时无须理会,暂且体验一下:

describe('AppComponent', () => {
    let fixture: ComponentFixture<TestComponent>;
    let context: TestComponent;

    beforeEach(() => {
        TestBed.configureTestingModule({
            declarations: [TestComponent]
        });
        fixture = TestBed.createComponent(TestComponent);
        context = fixture.componentInstance;
        // 监听onSelected方法
        spyOn(context, &#39;onSelected&#39;);
        fixture.detectChanges();
    });

    it(&#39;should be called [selected] event.&#39;, () => {
        // 触发selected操作

        // 断言是否被调用过
        expect(context.onSelected).toHaveBeenCalled();
    });
});

异步支持

首先,这里的异步是指带有 Observable 或 Promise 的异步行为,因此对于组件在调用某个 Service 来异步获取数据时的测试状态。

假设我们的待测试组件代码:

export class AppComponent {
  constructor(private _user: UserService) {}

  query() {
    this._user.quer().subscribe(() => {});
  }
}

async

async 无任何参数与返回值,所有包裹代码块里的测试代码,可以通过调用 whenStable()所有待处理异步行为都完成后再进行回调;最后,再进行断言操作。

it(&#39;should be get user list (async)&#39;, async(() => {
    // call component.query();
    fixture.whenStable().then(() => {
        fixture.detectChanges();
        expect(true).toBe(true);
    });
}));

fakeAsync

如果说 async 还需要回调才能进行断点让你受不了的话,那么 fakeAsync 可以解决这一点。

it(&#39;should be get user list (async)&#39;, fakeAsync(() => {
    // call component.query();
    tick();
    fixture.detectChanges();
    expect(true).toBe(true);
}));

这里只是将回调换成 tick(),怎么样,是不是很酷。

Jasmine自带异步

如前面所说的异步是指带有 Observable 或 Promise 的异步行为,而有时候我们有些东西是依赖 setTimeout 或者可能是需要外部订阅结果以后才能触发时怎么办呢?

可以使用 done() 方法。

it(&#39;async demo&#39;, (done: () => void) => {
    context.show().subscribe(res => {
        expect(true).toBe(true);
        done();
    });
    el.querySelected(&#39;xxx&#39;).click();
});

四、结论

本章几乎所有的内容在Angular单元测试经常使用到的东西;特别是异步部分,三种不同异步方式并非共存的,而是需要根据具体业务而采用。否则,你会发现真TM难写单元测试。毕竟这是一个异步的世界。

自此,我们算是为Angular写单元测试打下了基础。后续,将不会再对这类基础进行解释。

happy coding!

相关教程推荐:angular教程

Das obige ist der detaillierte Inhalt vonEinführung in Angular-Unit-Tests mit Jasmine. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:segmentfault.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen