Was getestet werden soll, im Gegensatz zu Tests ist eine wichtige Frage für alle Teams. Das Testen ist ein Mittel zum Zweck und die Entscheidung, wie das Testen verschiedener Teile Ihrer Codebasis priorisiert werden soll, kann schwierig sein.
Die beste Möglichkeit zur Priorisierung basiert auf Ihrer Codebasis und den Zielen Ihres Teams. Sie sollten jedoch bedenken, dass das Schreiben vieler kleiner Tests (z. B. mit Einheitentests) am unteren Rand der Testpyramide, die eine hohe Codeabdeckung aufweisen, zwar wenig Zeit und Bandbreite in Anspruch nimmt, das Gesamtrisiko für Ihr Projekt aber nicht unbedingt reduzieren.
Du kannst auswählen, was zuerst getestet werden soll, indem du die primären Anwendungsfälle deiner Anwendung, Website oder Bibliothek berücksichtigst. Erstellen Sie dazu Komponententests für kritische Bereiche Ihrer Website, die für die Nutzererfahrung entscheidend sind. Entwickler einer Website, die Nutzern das Hochladen und Verwalten von Zeitreihendaten ermöglicht, sollten sich beispielsweise überlegen und testen, wie ein Nutzer diese Aufgaben ausführen könnte.
Ein weiterer Ansatz der Priorisierung besteht darin, möglichst viele Informationen zu gewinnen. Wenn Sie einen "gefährlichen", veralteten oder schlecht geschriebenen, tragenden Teil Ihrer Codebasis haben, an dem niemand in Ihrem Team gerne arbeitet, kann es nützlich sein, Tests um ihn herum zu erstellen, um sein Verhalten einheitlicher zu gestalten, bevor Sie ihn entweder weiter ignorieren oder ihn refaktorieren, um das Problem zu beheben. Stellen Sie sich dies wie ein Gerüst für ein Gebäude vor, das bereits verurteilt wurde, aber noch Ihr Rechenzentrum beherbergt.
Dimensionalität
Wir haben das Konzept einer Testpyramide oder eine andere Testform eingeführt, aber diese stellen in der Regel nur eine einzige Testdimension dar: eine Linie, die von einem kleinen Umfang, einfachen Einheitentests bis hin zu komplexen, weitreichenden Tests reicht – Einheitentests gegen Integrationstests im Vergleich zu End-to-End-Tests.
Einige der langen Liste möglicher Testtypen stellen jedoch keine Komplexität dar, sondern Testziele oder -techniken. Rauchtests sind beispielsweise eine andere Kategorie von Tests, die selbst Unit-, End-to-End- oder andere Tests sein können. Sie sollen den Testern jedoch das Gefühl geben, dass das getestete Projekt in einem gültigen Zustand ist. Visuelle Tests können auch auf eine kleine Komponente oder auf die gesamte Website angewendet werden.
Für Ihre Codebasis gelten spezifische Anforderungen. Es kann beispielsweise in Ihrer Codebasis weitaus wichtiger sein, sich auf ein einzelnes Feature auszurichten und verschiedene Arten von Tests zu schreiben, um die korrekte Funktionsweise sicherzustellen. Ein neues Feature, das getestet werden muss, ist selten eine einzelne Komponente, eine Funktion oder ein Ansatz. Ihr Einfluss auf Ihr Projekt kann sich in großem Umfang und in unterschiedlichem Umfang verteilen.
Ihre Testprioritäten können auch von Ihren Geschäftsanforderungen abhängen. Hochtechnische Systeme erfordern unter Umständen komplexe Einheitentests, um zu bestätigen, dass ein einzigartiger Algorithmus korrekt funktioniert. Bei sehr interaktiven Tools hingegen konzentrieren sich die Tools eher auf visuelle Tests oder End-to-End-Tests, um zu bestätigen, dass komplexe Touch-Eingaben die richtige Antwort hervorrufen.
Ihr Testansatz
Versuchen Sie, sich auf das Testen der Anwendungsfälle Ihrer Codebasis zu konzentrieren, unabhängig von deren Umfang. Stellen Sie sich vor, wie der Nutzer einen beliebigen Teil Ihres Projekts verwenden könnte. Dies kann eine einzelne Komponente, eine untergeordnete Funktion oder einen übergeordneten End-to-End-Anwendungsfall darstellen. (Dadurch können auch Mängel in Ihren Abstraktionen beliebiger Größenordnung aufgedeckt werden, wenn Sie feststellen, dass Ihr Test nicht reibungslos mit dem zu testenden Code interagieren kann.)
Es ist wichtig, dass jeder Testlauf ein klar definiertes Ziel hat. Große „Catchall-Tests“ können sehr mühsam sein, genau wie in Ihrem Nicht-Testcode.
Ein Aspekt der testbasierten Entwicklung
Die testgesteuerte Entwicklung (Test-Driven Development, TDD) ist ein einzigartiger Ansatz für Tests – orthogonal oder Typen –, da dabei Tests geschrieben werden, die zumindest zu Anfang fehlschlagen sollen. Dies kann sowohl für manuelle als auch für automatisierte Tests gelten: Sie beschreiben die Ziele, die Sie erreichen möchten, finden heraus, was in Ihrer aktuellen Lösung oder Ihrem aktuellen Code fehlt, und verwenden den fehlgeschlagenen Test als Anleitung für eine Lösung.
Natürlich ist es nicht sinnvoll, jedes mögliche Szenario in einer hypothetischen Anwendung oder Komponente zu testen, noch bevor Sie damit beginnen. TDD hat seinen Platz und kann hilfreich sein, wenn Ihre Codebasis immer komplexer wird.
TDD ist auch eine gute Praxis bei der Behebung von Fehlern. Wenn Sie den Reproduktionsfall für einen Fehler codieren können, können Sie diesen in einen automatisierten Test umwandeln, der anfangs fehlschlägt. Wenn Sie den Fehler behoben haben, gilt der Test als bestanden und Sie können feststellen, ob die Korrektur ohne manuelle Bestätigung erfolgreich war.
Undurchsichtig im Vergleich zu transparenter Box
Dies bezieht sich auf die Art und Weise, wie Sie einen beliebigen Teil Ihres Systems testen. Wenn sie undurchsichtig ist, können Sie z. B. nicht drinnen sehen, wenn Sie die öffentliche Schnittstelle einer Klasse verwenden, anstatt ihr Inneres zu prüfen.
Sofern Sie keinen bestimmten Grund haben, sollten Sie lieber mit opaque-Box-Tests beginnen. So können Sie Tests basierend auf der Verwendung Ihrer Komponenten entwerfen und sich nicht durch die Funktionsweise ihrer internen Strukturen ablenken lassen. Wenn Sie nur die „öffentliche“ Schnittstelle eines Codepfads verwenden, die nicht unbedingt öffentlich für Ihre Nutzer, sondern vielleicht für andere Teile Ihres Codes ist, können Sie diesen Code refaktorieren und verbessern, in dem Wissen, dass Ihr Test alle Änderungen erkennt.
Eine Möglichkeit, Ihren „Clear-Box“-Code intransparenter zu machen, besteht darin, konfigurierbare Elemente wie Abstraktionen für die Abhängigkeiten des Codes oder Callbacks zur Beobachtung des Zustands einzuführen, anstatt dass dieser Zustand eng an andere Systeme gekoppelt ist. Dadurch ist Ihr Code entkoppelt und Sie können Testversionen bereitstellen. Alternativ können Sie simulieren, wo Ihr Code mit anderen Systemen interagiert.