Die fehlende Zutat für die Codeabdeckung von Angular-Templates und zukunftssicheres Testen

TL;DR: Aktivieren Sie die AOT-Kompilierung (Ahead-Of-Time) für Ihre Angular-Tests, um eine genaue Vorlagencodeabdeckung, eine schnellere Testausführung, Produktionssymmetrie und Zukunftssicherheit zu erhalten Tests.

Die Option ist bereits für Vitest-Benutzer verfügbar und wird bald für Benutzer von Karma und Jest (experimenteller Builder) verfügbar sein.

? Was ist falsch an JIT?

Ob Sie Karma, Jest oder Vitest verwenden, Sie verwenden wahrscheinlich die Just-In-Time-Kompilierung (JIT) für Ihre Angular-Tests, da bis vor kurzem die einzige verfügbare Option war.

Das Problem besteht darin, dass JIT einige erhebliche Nachteile hat:

• Die Codeabdeckung ist nicht korrektda die Vorlage nicht berücksichtigt wird.
• Es ist langsamer, da die Tests die Vorlagen im laufenden Betrieb kompilieren.
• Es ist nicht zukunftssicher, da Angular die Grenzen der JIT-Kompatibilität erreicht hat. Einige Funktionen sind mit JIT konstruktionsbedingt einfach nicht umsetzbar.
• Es ist nicht symmetrisch zur Produktionsumgebung, in der AOT verwendet wird.

⏰ Warum jetzt?

Seit Angular 8 und der Einführung von IVy hat der Angular-Compiler damit begonnen, Vorlagen in Anweisungen umzuwandeln. Neben vielen anderen Vorteilen bedeutete dies auch, dass Code-Coverage-Tools diese Anweisungen der Vorlage zuordnen und die Code-Coverage entsprechend berechnen konnten.

Theoretisch ist es seit Angular 8 möglich, Codeabdeckung durch die Ausführung von Tests mit AOT zu erzeugen, in Karma oder Jest war diese Option jedoch nicht verfügbar. Es war erst möglich, AOT zum Testen zu aktivieren, seit das Analog-Team die Vitest-Unterstützung für Angular hinzugefügt hat.

Stand November 2024:

• Vitest ist die einzige Option, die die AOT-Kompilierung unterstützt.
• Es gibt offene PRs für Karma und Jest Experimental Builder zur Unterstützung von AOT.

? Weitere Vorteile von AOT-Tests

⚡️ Schnellere Testausführung

Unabhängig davon, ob Sie JIT oder AOT verwenden, werden Komponenten irgendwann kompiliert. Der Hauptunterschied besteht darin, dass bei AOT die Kompilierung einmal durchgeführt wird und zwischengespeichert werden kann, während bei JIT jedes Testmodul möglicherweise Komponenten neu kompiliert.

Das bedeutet, dass die gesamte Testausführungszeit schneller ist, selbst wenn die Transformationsphase mit AOT etwas langsamer ist. Die Zahlen, die ich gesehen habe, deuten auf eine ungefähr 20 % schnellere Ausführung hin, aber dies hängt stark von der Struktur Ihrer Tests und dem zu testenden System ab.

? Produktionssymmetrie

Im Allgemeinen möchten wir, dass unsere Tests so symmetrisch wie möglich zur Produktionsumgebung sind, um das Vertrauen zu erhöhen. Dies ist oft eine Herausforderung, da es mit anderen Eigenschaften wie der Geschwindigkeit der Tests, der Größe des zu testenden Systems oder der Vorhersagbarkeit im Gleichgewicht steht.

Das Interessante an AOT ist, dass es die Produktionssymmetrie verbessert, ohne andere Eigenschaften zu beeinträchtigen. Durch den Einsatz von AOT gewinnen Sie mehr Selbstvertrauen und erreichen ein produktionsnäheres Verhalten.

? Zukunftssichere Tests

Noch wichtiger ist, dass JIT seine Grenzen erreicht hat und zu einer Belastung für Angular wird. Beispielsweise werden einige Angular-Funktionen in JIT einfach nicht unterstützt (z. B. Deferrable Views). Andere potenzielle Funktionen aus der Angular-Roadmap, wie z. B. wählerlose Komponenten, werden wahrscheinlich nicht mit JIT verwendet werden können.

Tatsächlich erfordert JIT seit den Signaleingängen von Angular (und ähnlichen funktionalen APIs) bereits einige minimale Transformationen, um zu funktionieren.

Durch den Wechsel zu AOT machen Sie Ihre Tests zukunftssicher, bereit, von jeder Innovation zu profitieren, und auf alles vorbereitet, was die Zukunft für JIT bereithält.

? Nachteile

? Dynamische Komponentenkonstrukte sollten vermieden werden

Durch die Aktivierung von AOT werden einige Techniken, die auf dynamischen Konstrukten basieren, nicht mehr funktionieren.

Eine solche Verwendung funktioniert beispielsweise nicht mehr:

// ? 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);
}

Das Umgehen der AOT-Kompilierung ist jedoch weiterhin möglich (⚠️ vorerst ️⚠️):

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

  return TestBed.createComponent(TestContainer);
}

Mein Rat ist, solche Konstrukte so weit wie möglich zu vermeiden und bei Bedarf lieber testspezifische Komponenten zu erstellen, auch wenn es vielleicht etwas ausführlicher ist. In Zukunft könnte das Angular-Team Alternativen bereitstellen, die sowohl AOT-kompatibel als auch weniger standardisiert sind.

? Flache Tests sind anspruchsvoller

Auch wenn Shallow Testing nicht Ihre primäre Teststrategie sein sollte, da es auch weniger produktionssymmetrisch ist, ist es dennoch eine nützliche Technik, die Sie in Ihrem Werkzeugkasten haben sollten.

Mit AOT ist es derzeit nicht möglich, die Importe einer Komponente mit TestBed#overrideComponent zu überschreiben.

Die Problemumgehung besteht darin, die Abhängigkeiten der Komponente auf Modulebene mithilfe der API des Test-Frameworks zu überschreiben und Komponenten durch ihre Test-Doubles zu ersetzen.

Zum Beispiel mit 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 {
  // ...
}

Diese vorübergehende Problemumgehung ist zwar AOT-kompatibel, aber mit Kosten verbunden:

• Es ist weniger lesbar und ausführlicher.
• „Verspotten“ (oder Bereitstellung von Testdoppeln) auf Modulebene ist weniger detailliert und kann weniger vorhersehbar sein.
• Es ist stark an das von Ihnen verwendete Test-Framework gekoppelt.

Im Moment würde ich die Verwendung von JIT für flache Tests empfehlen, bis TestBed#overrideComponent AOT unterstützt oder bis das Angular-Team eine bessere Alternative bereitstellt. Sie können dies erreichen, indem Sie eine separate Konfiguration für Shallow Tests verwenden, die JIT für Tests verwenden, die einem bestimmten Muster wie *.jit.spec.ts.

entsprechen

???‍? Probieren Sie Vitest mit AOT aus

1. Vitest einrichten

• Benutzer von Angular CLI verwenden das Schema von Analog.
• Für Nx-Benutzer wählen Sie beim Generieren einer Anwendung oder Bibliothek die Option „vitest“ (verfügbar seit Nx 20.1.0).

2. AOT aktivieren

Suchen Sie die Datei vite.config.js und aktivieren Sie AOT, indem Sie die Plugin-Jit-Option von Angular auf false setzen:

// ? 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);
}

? Konfigurieren Sie die Codeabdeckung

Wir haben die Möglichkeit, entweder Istanbul oder Native v8 für die Codeabdeckung zu verwenden. Aus irgendeinem Grund, der noch untersucht wird, schlägt die Neuzuordnung der Vitest-Abdeckung bei Verwendung von Version 8 fehl. Die Lösung besteht darin, stattdessen auf Istanbul zurückzugreifen.

1. Installieren Sie @vitest/coverage-istanbul

Stellen Sie sicher, dass Sie die Version von Vitest Istanbul installieren, die mit der Hauptversion von Vitest
übereinstimmt

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

  return TestBed.createComponent(TestContainer);
}

2. Wählen Sie Istanbul als Ihren Versicherungsanbieter

Aktualisieren Sie vite.config.mts, um die Abdeckung über Istanbul zu ermöglichen:

// 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 {
  // ...
}

? Sehen Sie es sich in Aktion an

Sie können jetzt die Tests ausführen:

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

Klicken Sie dann auf das Abdeckungssymbol und bewundern Sie die Codeabdeckung der Vorlage. ?

(Den Abdeckungsbericht finden Sie auch im Abdeckungsordner)

Beachten Sie, dass die Abdeckung auf der Grundlage der vom Compiler generierten Anweisungen berechnet wird, was Folgendes bedeutet:

Es funktioniert sogar für Strukturanweisungen.

Jetzt wissen Sie was!?

Die Abdeckung funktioniert auch für Inline-Vorlagen! ?

☢️ Beachten Sie die Code-Coverage-Falle

Obwohl die Codeabdeckung ein nützliches Werkzeug ist, sollte sie mit Bedacht eingesetzt werden. Behalten Sie es als Indikator und nicht als starres Ziel.

Jede beobachtete statistische Regelmäßigkeit neigt dazu, zusammenzubrechen, sobald zu Kontrollzwecken Druck auf sie ausgeübt wird.

-- Charles Goodhart

Mit anderen Worten: Wenn eine Maßnahme zum Ziel wird, ist sie keine gute Maßnahme mehr.

Ich möchte hinzufügen, dass die einfachsten Messwerte oft am irreführendsten sind.

? Was kommt als nächstes?

Karma-Benutzer können AOT bald mit einer einfachen Flagge aktivieren.

Jest-Benutzer haben drei Möglichkeiten:

• Empfohlen: Migration zu Vitest. (? Bleiben Sie dran, ich werde Ihnen bald den reibungslosesten Migrationspfad vorstellen)
• Verwenden Sie den experimentellen Builder mit AOT.
• Warten Sie auf die Jest-Preset-Angular-AOT-Unterstützung.

Vitest-Benutzer können jetzt die Vorteile von AOT genießen. ?

? Zusätzliche Ressourcen

• ? Demo-Repo
• ? Angular Ahead-Of-Time (AOT) Compiler-Dokumente
• ? Vitest-Dokumente
• ? Analogs Dokumente zu Vitest

???‍? Der Videokurs zum Pragmatischen Angular-Testen ist da!

Wenn Sie genug von Fehlern oder wartungsintensiven Tests haben, die bei jedem Refactoring abbrechen, hilft Ihnen mein Videokurs „Pragmatic Angular Testing“!

Lernen Sie praktische, zuverlässige Teststrategien, um Ihre Angular-Apps stabil und wartbar zu halten. (Jetzt 50 % Rabatt für begrenzte Zeit!)

Das obige ist der detaillierte Inhalt vonDie fehlende Zutat für die Codeabdeckung von Angular-Templates und zukunftssicheres Testen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!