Automatisieren der Erstellung von Komponententests

Welche Strategien könnten verwendet werden, um die Erstellung von Unit-Testfällen zu automatisieren? Welche Aspekte müssten Sie in jeder Klasse berücksichtigen, um mindestens ein anständiges Testfallgerüst zu generieren?

Mir ist klar, dass eine umfassende automatische Lösung nicht praktikabel ist, aber ich möchte die Testerstellung zumindest ein wenig beschleunigen, indem ich ein Skelett erstelle. Ich suche keine Codebeispiele, nur vielleicht einige Vorschläge, wo ich anfangen soll, oder Beispiele dafür, wo so etwas getan wurde, damit ich sehen kann, wie sie es angegangen sind und was möglich sein könnte.

Ich interessiere mich besonders für Methoden zum Erstellen von Unit-Test-Skeletten in PHP, die nicht alle Tools bieten, die andere Sprachen bieten, wie zum Beispiel vollständige Typhinweise .

Ihre Strategie und Ihr Skelett hängen nicht trivial davon ab, welche Arten von Tests Sie generieren möchten, welche Art von Berichterstattung Sie suchen und in welcher Sprache / Umgebung Sie arbeiten.

Es ist ziemlich einfach, einen Testgenerator zu schreiben, der für Sprachen wie C oder Java Klassensignaturen liest und automatisch Tests für Standard-Eckfälle generiert (Übergabe von 0, 2 Zufallswerten, MAX_INT, MIN_INT, an ein ganzzahliges Argument, Nullen für Nullwerte , etc...). Sie können dann die generierten Tests ausführen, die Ergebnisse für jeden Test aufzeichnen und manuell filtern, um irrelevante zu entfernen, akzeptable Ergebnisse für Tests zu genehmigen, die bestanden wurden (damit sie fortan automatisch bestanden werden können), und als ungültige Tests markieren, die fehlschlagen .

Sie können dies durch Markieren / Kommentieren / Umgestalten von Klassen ergänzen, um Ihrem Generator zusätzliche Hinweise zu geben. Möglicherweise haben Sie ein Tag, das alle möglichen Ausnahmen auflistet, die ein Methodenaufruf auslösen darf, oder das einen reduzierten Bereich gültiger Ganzzahlen für ein Ganzzahlargument angibt. Betrachten Sie diese als Kurzform, um die Tests selbst schreiben zu müssen.

Hier sind einige Komponenten, die Sie sich ansehen möchten:

• Eine Komponente zum automatischen Analysieren von Quellcode- / Funktionssignaturen / manuellen Anmerkungen, Erstellen von Standardtestfällen oder Umrissen / Signaturen für Testfälle, die darauf warten, dass Ihre Eingabe abgeschlossen wird.
• Eine ständig wachsende / sich ändernde Sprache von Tags / Anmerkungen / Kommentaren, die bis zu einem beliebigen Grad an Granularität (Methode / Klasse / Signatur / while-Schleifen / etc ...) reichen kann und Hinweise für den automatisierten Test-Builder darstellt. Idealerweise sollten Sie in der Lage sein, mit dieser Sprache zu spielen, ohne Ihr Framework oder Teile davon neu codieren zu müssen
• Automatisierter Testläufer mit der Fähigkeit, neue / alte Tests zu identifizieren und für jeden Test "akzeptable" Antworten aufzuzeichnen / zu testen. Idealerweise erstellt dieser Läufer eine Datenbank mit Testläufen, akzeptierten / abgelehnten Ergebnissen und aktuell akzeptablen Ergebnissen für jeden Test.
• Automatisierter "Objektfälscher", der bei einem Klassennamen und einer Zuordnung von Namen-> Werten ein Objekt erzeugen kann, das die Klasse nachahmt und anpassbare Daten für Funktionsaufrufe, Accessoren, öffentliche Datensteckplätze usw. zurückgibt.

Es gibt viele Test-Frameworks, die bereits Teile dieser Funktionalität für verschiedene Sprachen und Plattformen enthalten. Es ist zwar ziemlich einfach, diese Arbeit selbst zu erledigen und diese Art von Framework intern intern zu erweitern, aber es ist auch ein endloses langfristiges Projekt, das wahrscheinlich vorhandene Arbeiten duplizieren wird. Ich würde empfehlen, sich viel Zeit zu nehmen, um zuerst zu prüfen, was verfügbar ist, und dann zu entscheiden, ob es sich lohnt, einzutauchen.

Ich hatte noch keine Gelegenheit, es für eine Anwendung mit einer bedeutenden Größe oder Komplexität zu verwenden, aber es gibt Tools, einschließlich CodePro AnalytiX von Google , die die Generierung von Komponententests für Java-Anwendungen automatisieren . Ich habe auch ein kommerzielles Produkt gefunden, Parasofts C ++ - Test , das anscheinend die Generierung von C ++ - Komponententests ermöglicht

Diese Anwendungen verwendeten Heuristiken, um Testfälle zu generieren. Ich bin nicht sicher, ob es ein einziges Framework gibt, mit dem Sie ein Skelett erstellen können, aber es gibt Konstrukte, nach denen Sie suchen können. Ich neige dazu, mich auf Schleifen, bedingte Anweisungen ( ifBlöcke, switch/ caseAnweisungen) und Ausnahmen zu konzentrieren und Testfälle zu erstellen, die die Ausführung unterschiedlicher Ausführungspfade erzwingen.

Ich würde mich nicht darauf konzentrieren, das Schreiben von Tests zu beschleunigen, indem ich versuche, ein Skelett oder eine Vorlage zu erstellen, sondern die Analyse der Spezifikation und / oder Implementierung zu verbessern und qualitativ hochwertige Tests zu schreiben. Die Möglichkeit, frühzeitig zu erkennen, welche Tests den größten Mehrwert bieten, diese zu schreiben und später Löcher zu füllen, hätte einen größeren Einfluss auf Produktivität und Qualität.

Um mehr Werbung zu machen, probierte Falcon CodePro für ein Projekt aus und schrieb einen kleinen Klappentext über seine Erfahrungen .

Ich habe vor einigen Jahren einen Generator geschrieben, um das Testen von Einheiten für ein .NET-Projekt zu beschleunigen. Es gab eine große Codebasis ohne Komponententests, die darauf abzielte, die Grundabdeckung schnell zu erhöhen. Hier sind einige Hinweise, die hilfreich sein könnten:

• Meine Chance bestand darin, dass das Kernframework, auf dem das Projekt entwickelt wurde, Standardoperationen und Klassennamen bereitstellte. Wenn Sie daran denken, Ihre eigenen zu schreiben, hilft eine Standardstruktur wie diese sehr.
• Die Verwendung data-driven testinghilft sehr, wenn Ihre Codebasis dies zulässt. Das Testframework erstellte für jeden Komponententest eine Datenbanktabelle zum Speichern von Testdaten, sodass jede Zeile in dieser Tabelle ein separater Test war und kein zusätzlicher Code erforderlich war ( Repräsentationsregel ). Ab diesem Zeitpunkt können die eigentlichen Tests einfach automatisch erstellt oder manuell eingegeben werden.
• Die resultierenden Unit-Tests waren einfach, dienten aber smoke testzumindest als s. Für Bereiche mit höherem Risiko wurden zusätzliche manuelle Tests geschrieben.

Zusammenfassend stimme ich zu, dass eine generische Lösung unpraktisch wäre (wenn es möglich ist). Ich glaube, die Chancen stehen besser, wenn die Codebasis für die Testgenerierung geeignet ist und das Testframework seine Struktur nutzen kann.

(Als Randnotiz gibt es Pex , aber es ist für .NET)