Erfahren Sie, wie die Continuous Quality Platform von Parasoft dabei hilft, Testumgebungen zu steuern und zu verwalten, um zuverlässig hochwertige Software zu liefern. Für Demo registrieren >>
Unit-Tests sind seit Jahren eine branchenweit bewährte Methode. Wenn Entwicklungsteams ihre Testsuiten ausbauen, werden sie immer größer. Wenn die Tests zu Integrations- oder Komponententests erweitert werden, dauert die Ausführung länger. Mit neuen Trends bei Unit-Tests wie TDD werden diese Testsuiten noch größer als zuvor, da der gesamte Code von Tests abhängt und mehr davon.
Eine große Grundlage für Komponententests kann eine hervorragende Grundlage für Tests sein. Dies kann jedoch einen großen Einfluss auf die Testausführungszeit haben, insbesondere wenn sich die Komponententests auf Tests auf Integrations- / Komponentenebene ausweiten. Der Schlüssel zum Wissen, was getestet werden muss, besteht darin, die genauen Auswirkungen jeder Codeänderung zu verstehen, welche Tests ausgeführt werden müssen und welche neuen Tests möglicherweise erforderlich sind.
Die Berechnung der Codeabdeckung ist ein Aspekt bei der Bestimmung der getesteten Daten, reicht jedoch allein nicht aus. Die wahre Magie entsteht, wenn die Codeabdeckung für jeden Test berechnet und dann Build für Build mit Änderungen im Code korreliert wird. Mit diesem Ansatz erhalten wir Test Impact Analysis - Mit diesem Verfahren identifizieren wir genau, welcher Test ausgeführt werden muss, um Codeänderungen zu validieren. Durch die Nutzung der Testauswirkungsanalyse für Komponententests mit Parasoft Jtest können Softwareentwicklungsteams ihre Testbemühungen konzentrieren und ihre Entwicklungspipeline über den IDE- oder CI-Prozess wirklich beschleunigen.
Das frühzeitige Auffinden und Beheben von Fehlern ist der Hauptvorteil einer Testauswirkungsanalyse. Mit den Ergebnissen der Testauswirkungsanalyse, die direkt in die IDE integriert sind, können Entwickler die Vorteile nahtlos in ihren Workflow nutzen, um die Testbemühungen genau an der richtigen Stelle zu konzentrieren und sicherzustellen, dass Codeänderungen vollständig getestet werden, einschließlich indirekter Auswirkungen auf verwandten Code.
Obwohl das frühzeitige Auffinden und Beheben von Fehlern das Hauptziel ist, bietet es weitere Vorteile, die Ergebnisse der Testauswirkungsanalyse dem Entwickler zur Verfügung zu stellen, darunter:
Wenn Sie die Testauswirkungsanalyse mit dem CI-Prozess kombinieren, können Sie Zeit sparen und die Bemühungen des Entwicklungsteams auf genau das konzentrieren, was zur Qualitätssicherung getan werden muss. Optimierungen zu Entwicklungs- und Erstellungszeiten sind entscheidend für das Erreichen agiler Ziele im Umgang mit Änderungen.
Das frühere Auffinden von Fehlern ist besser und billiger als das spätere Auffinden von Fehlern im Lebenszyklus der Softwareentwicklung, was zu erheblichen Zeitverschiebungen führen kann. Entwickler wissen oft nicht, welche Tests sie ausführen sollen, daher führen sie entweder keine oder zu wenige Tests aus. In diesem Fall hängen sie vom Build ab, der für die Ausführung der gesamten Testsuite eingerichtet ist. Daher sind Entwicklungsteams untätig, da sie auf Feedback / Validierung des Build-Prozesses bezüglich ihrer Änderungen warten. Durch die Nutzung der Testauswirkungsanalyse können Entwicklungsteams die entsprechenden Tests finden und ausführen, bevor sie Code in einen Build übertragen, um die Änderungen zu validieren.
Eine Analyse der Testauswirkungen bedeutet auch, dass Entwickler schnelleres Feedback zu Codeänderungen erhalten können, die zu Testfehlern in ihrem CI-Prozess führen. Entwicklungsmanager möchten, dass ihre Teams im Idealfall Tests durchführen, bevor der Code eingecheckt wird, dies wird jedoch häufig nicht durchgeführt. Darüber hinaus möchten sie sicherstellen, dass ihre Teams nach dem Einchecken des Codes so schnell wie möglich wissen, ob der Code Tests gebrochen hat. Daher ist es wichtig, dass die Testauswirkungsanalyse sowohl den CI-Prozess als auch den Desktop des Entwicklers umfasst.
Wie sieht das in der Praxis aus? Während der Entwickler in der IDE Code schreibt, enthält die Ansicht „Impacted Unit Tests“ von Jtest eine (sich dynamisch entwickelnde) Liste der Tests, die ausgeführt werden müssen, um den lokal geänderten Code auszuführen. Dann muss der Entwickler nur noch mit der rechten Maustaste auf den betroffenen Test klicken und ihn ausführen oder einfach alle betroffenen Tests ausführen.
Jtest verfolgt die betroffenen Tests, die ausgeführt wurden, und zeigt deutlich an, welche bestanden und welche fehlgeschlagen sind. Auf diese Weise kann der Entwickler leicht feststellen, welche Tests noch ausgeführt werden müssen oder welche Tests fehlgeschlagen sind und behoben werden müssen. Sobald alle Tests ausgeführt wurden und bestanden wurden, hat der Entwickler mehr Vertrauen in die Codeänderung und kann seinen Code sicher festschreiben und mit der nächsten Entwicklungsaufgabe fortfahren.
Der Code-Test-Feedback-Korrektur-Workflow wurde speziell entwickelt, um die Produktivität auf dem Desktop des Entwicklers zu steigern, sodass Benutzer auf einfache Weise nur die Tests identifizieren und ausführen können, die zur Überprüfung lokaler Codeänderungen erforderlich sind. In einem Modell, das direkt für die Produktion bereitgestellt wird, wird verhindert, dass Fehler zu Endbenutzern gelangen. Wenn mehrere Teams an einem Projekt beteiligt sind, wird verhindert, dass Zeit für andere Teams verloren geht, die Probleme beheben und Probleme lösen müssen, die hätten vermieden werden können, wenn die entsprechenden Tests ausgeführt worden wären, bevor der Code festgeschrieben wurde.
Tools funktionieren nicht, wenn Sie sie nicht einfach in Ihre vorhandene Toolchain integrieren können. Parasoft Jtest unterstützt Projekte in der Git- oder SVN-Quellcodeverwaltung sowie andere Quellcodeverwaltungssysteme. Die IDE-Integration ist sowohl für Eclipse als auch für IntelliJ vorhanden. Jtest bietet Maven- und Gradle-Plugins, die in einen CI-Build-Job integriert werden können, der Tests als Teil eines Maven- oder Gradle-Builds ausführt.
Diese Plugins können so konfiguriert werden, dass eine Testsuite vollständig automatisiert wird, indem ermittelt wird, welcher Code sich seit dem Baseline-Build geändert hat, der häufig als letzter nächtlicher Build konfiguriert ist, und anschließend festgelegt wird, welche Tests ausgeführt werden müssen, um diesen Code auszuführen, und anschließend ausgeführt wird nur diese Untergruppe von Tests. Auf diese Weise kann ein Team einen CI-Job einrichten, der nur Tests basierend auf den letzten Codeänderungen ausführt. Dadurch kann die Zeit, die zum Ausführen eines CI-Jobs erforderlich ist, möglicherweise von Stunden auf Minuten verkürzt werden.
Als Best Practice können Teams jede Nacht die gesamte Suite von Komponententests durchführen und die Analyse der Testauswirkungen in den täglichen (Zwischen-) Builds nutzen. Dies macht Parasoft Jtest besonders vorteilhaft für Teams mit lang laufenden Testsuiten, die echte CI erhalten können, indem sie innerhalb von Minuten nach dem Festschreiben von Code Ergebnisse aus relevanten Tests erhalten. Ohne dies zu können, können schlechte Codeänderungen zu Regressionen führen, die nicht so schnell abgefangen werden und sich somit in die Produktion einschleichen oder die Arbeit anderer Teammitglieder beeinträchtigen können.
Durch die Fokussierung der Ressourcen auf genau das, was getestet werden muss, können Entwicklungsteams schnell und effizient Tests durchführen, um den Code, den sie ständig einchecken, zu überprüfen und Fehler und Sicherheitslücken zu erkennen, bevor sie den Build erreichen.
Kapil ist Produktmanager bei Parasoft und konzentriert sich auf Parasoft Jtest. Kapil hatte verschiedene technische Positionen inne, die vom Softwareentwickler bis zum Entwicklungsleiter reichten, bevor er zum Produktmanagement wechselte.