Anmerkung

Der Artikel spricht über die unkonventionelle, aber nützliche Form von Tests und fasst auch die Ergebnisse von sieben Jahren Arbeit bei der Entwicklung von Tests zusammen.

Warum brauchen Sie Komponententests?

Schließlich gibt es beispielsweise Unit-Tests, bei denen die Innereien von Bauteilen im Detail geprüft werden. Sie überprüfen gründlich, ob die Komponente in Übereinstimmung mit der Absicht des Entwicklers funktioniert. Aber oft ist dies eine Überprüfung der Knöpfe und nicht wie der Anzug als Ganzes sitzt. Und nicht immer stimmt das vom Programmierer konzipierte Verhalten mit dem überein, was der Kunde wollte.

Und es gibt zum Beispiel Abnahmetests. Und sie beseitigen all diese Mängel. Leider führen sie neue ein. Sie sind langsam, oft instabil und normalerweise zahm. Sie weisen jedoch nur auf ein Problem hin, lokalisieren es jedoch nicht.

Offensichtlich besteht Bedarf an Zwischentests, die das goldene Mittel zwischen Einheits- und Abnahmetests darstellen. Dieser Mittelweg kann Komponententests sein.

Was sind Komponententests?

Dies sind Tests für die öffentliche Komponenten-API. Dementsprechend sind sie in derselben Sprache wie die Komponente geschrieben. Testziel:

Überprüfen Sie die Übereinstimmung der Komponenten mit Ihren Verträgen
Überprüfen Sie die Konformität
Letzteres ist da besonders wichtig Unit-Tests werden normalerweise basierend auf den Erwartungen des Entwicklers geschrieben, aber hier müssen Sie die Erwartungen der Kunden überprüfen.

Komponententests sind natürlich sinnvoll, wenn Sie dedizierte Komponenten mit einer umfangreichen Oberfläche haben. Zum Beispiel eine dynamische Bibliothek oder ein COM-Objekt. Dann ergeben Komponententests die maximale Wirkung.

Vorteile von k-Tests:

Geben Sie der Entwicklung Stabilität. Eine umfassende Überprüfung der öffentlichen Schnittstellen ermöglicht es Ihnen natürlich, die Komponente in einer mehr oder weniger effizienten Form zu halten.
Lokalisieren Sie Probleme genau. Selbst wenn der Komponententest selbst recht allgemein ist, kann er immer eingehend getestet werden, um schnell zum Kampfcode zu gelangen. In diesem Fall ist die Testumgebung minimal und wird automatisch konfiguriert.
Beschleunigen Sie die Entwicklung mit einer kritischen Anzahl von Entwicklern. Programmierer sind dafür bekannt, wie Pferde zu sein. Wenn ein Pferd einen Karren mit einem Fassungsvermögen von 1 Liter zieht. s., dann werden acht Pferde mit einem Fassungsvermögen von nur etwa 4 Litern gezogen. s Und das Hinzufügen eines weiteren Entwicklers zum Team (insbesondere am Ende des Projekts) beschleunigt oft nicht nur nicht, sondern verlangsamt es auch. Das Hinzufügen eines Komponententestentwicklers ist zwar immer von Vorteil, da es relativ unabhängig vom Team agiert: Es führt (im Wesentlichen externe) Tests durch, beschleunigt den Build des Builds, optimiert Assembly-Dateien usw.
Klären Sie die Kundenanforderungen (und überprüfen Sie sie anschließend). Da der Entwickler der Komponententests nicht an die Implementierung gebunden ist, ist er weniger vom Effekt "Ich weiß, wie es selbst geht" betroffen. Im Falle einer mehrdeutigen Anforderung neigt der gewöhnliche Entwickler dazu, dies bequem zu tun (interessanter, schneller, einfacher). Während der ct-Entwickler in diesem Fall geneigt ist, anzugeben, was genau vom Kunden erwartet wird.
Relativ stabil und relativ schnell (im Vergleich zu manuellen Tests und automatisierten Tests über die Benutzeroberfläche).

Nachteile von K-Tests:

Zeit für Entwicklung und Support. Offensichtlich wird die Alpha-Version des Produkts später angezeigt, wenn ein Teil der Zeit für das Schreiben von Komponententests aufgewendet wird. Wird es generell einen Gewinn geben? Wird es früher eine Veröffentlichung geben? Das ist eine gute Frage. Meine Meinung: Bei der Entwicklung mit Komponententests wird die Version ungefähr zur gleichen Zeit veröffentlicht. Aber - mit weniger Gerüchten und zeitlich vorhersehbarer. Die Entwicklungszeit wird natürlich länger, die Zeit für Bugfix und Stabilisierung wird reduziert. Da der zweite Teil viel weniger vorhersehbar ist, wirkt sich seine Reduzierung positiv auf den Verarbeitungsaufwand und den Aufwand aus. Dies ist jedoch nur meine Erfahrung, und die Realität kann anders sein. Es ist möglich, dass die für Komponententests vorgesehene Zeit nicht ordnungsgemäß für das Duplizieren vorhandener Komponententests verwendet wird.
Weniger Austauschbarkeit. Die Rollentrennung erhöht die Effizienz, verringert jedoch die Austauschbarkeit. Entwickler möchten selten tief in Komponententests eintauchen, die eine ziemlich komplexe Umgebung haben (oder simulieren) können. Die Entwickler von Komponententests sind weit davon entfernt, den Kampfcode so gut zu kennen, dass er leicht bearbeitet werden kann.
Ärgerliche Vervielfältigung. Bei guten Komponententests erweisen sich Komponententests häufig als größtenteils redundant. Dies ist sowohl ärgerlich als auch stellt ihre Bedürfnisse in Frage. Die Koordination von Einheitenplänen und Komponententests hilft, aber in der Regel werden Doppelarbeit nicht vollständig beseitigt.
Die Notwendigkeit, den richtigen Workflow zu befolgen. Nach Erhalt der Anforderungen sollte die Aufgabe gleichzeitig dem Entwickler und dem Entwickler der Tests übertragen werden. Dann beenden sie die Arbeit ungefähr zur gleichen Zeit. Die Komponente wird Tests unterzogen, Fehler werden schnell erkannt und korrigiert, und zum Beenden wird ein mehr oder weniger fertiges Produkt verwendet. In diesem Fall werden die Vorteile von Komponententests maximiert. Es kommt jedoch häufig vor, dass die Fristen lange Zeit profan sind, nur Code geschrieben wird und die Komponente ohne Tests manuell getestet wird. Und erst dann laden sie den Entwickler der Tests ein - sie sagen, es ist nicht gut, dass der Code ohne die Tests veröffentlicht wurde, wir sollten sie hinzufügen. In diesem Fall sind die meisten Fehler Handheld-Tester, Entwickler nehmen Korrekturen blind vor (oder testen die Änderungen selbst mit den Händen), und Post-Factum-Tests stellen nur eine geringe Anzahl von Fehlern fest (was sich negativ auf die Moral ihres Autors auswirkt). Eine solche Verwendung von Komponententests ist bestenfalls nutzlos und schwer zu versichern.
Es gibt nur wenige geeignete Personen. Der Entwickler von Komponententests sollte einerseits in der Lage sein, Code in der Sprache der Komponente (und dies beispielsweise in C ++) zu schreiben. Wenn die Umgebung zum Starten der Komponente umfangreich ist, kann der Code außerdem recht kompliziert sein. Auf der anderen Seite können Sie die Arbeit eines anderen akribisch testen. Es gibt nicht sehr viele solcher Leute, und sie gehen normalerweise sofort zu den Entwicklern. Aber es gibt immer noch solche Leute und den nächsten Teil über sie.

Zusammenfassung 1

Komponententests sind gut, aber nur, wenn Sie alle Voraussetzungen dafür haben: eine breite öffentliche API, den richtigen Workflow und die richtigen Mitarbeiter im Team.

Wie ist es, ein SDET zu sein?

Offensichtlich ist SDET - Software Development Engineer in Test ein idealer Kandidat für das Schreiben von Komponententests. Er weiß, wie man Code schreibt und wie man in Tests denkt. Es gibt auch eine zweite Meinung, die auch die Qualität von Tests und Code verbessert. Das klingt alles interessant und verlockend - vielleicht möchten Sie schon einer sein. Hier werde ich Ihnen kurz erklären, wie sich die Arbeit von SDET von der Arbeit eines reinen Entwicklers unterscheidet.

Vorteile der Arbeit mit SDET:

Neuer Code. Fast immer schreibt SDET Tests von Grund auf neu. Und oft genug wird eine Umgebung von Grund auf neu geschrieben. Es ist sehr schön und bietet viel Raum für Kreativität.
Geringe Abhängigkeit von Legacy-Code. Egal wie schrecklich der Kampfcode war, Tests dafür können kompetent und schön durchgeführt werden. Natürlich erzeugt schlecht gestalteter Code hässliche Tests, aber dennoch können sie um eine Größenordnung besser gemacht werden als der Code selbst.
Häufigeres Refactoring. Änderungen in Tests sind viel weniger gefährlich, daher werden sie häufiger vereinbart. Dies ist eine gute Gelegenheit, um Fehler zu beheben und das Schreiben von sauberem Code durch Refactoring zu üben.
Die Entwicklung des kritischen Denkens. Autotests sind eine interessante Suche, wie man den Code eines anderen bricht. Darüber hinaus ist die Suche nicht dumm, nicht draußen zu sitzen und zu stochern, sondern mit Hilfe von Logik, Kombinatorik und der Fähigkeit, Schwachstellen zu erkennen. Sobald ein Scheck erstellt wurde, funktioniert er weiterhin für Sie.
Entwicklung der Fähigkeit zum Testen von Code. Im Nahkampftraining geben sie oft einleitende Worte: "Jetzt arbeiten wir nur mit unseren Füßen; jetzt arbeiten wir nur mit unseren Köpfen." Wenn Sie nur einen Mechanismus verwenden (in unserem Fall Autotests), können Sie ihn zur Beherrschung verbessern.
Weniger Gerüchte. SDETs werden für das Wochenende viel weniger gezogen. Sie müssen nicht dringend zur Arbeit gehen, um kritische Fehler zu beheben. Nun, sie haben eine viel geringere Chance, einen schwerwiegenden Fehler zu machen.

Nachteile der Arbeit mit SDET:

Geringe Codierungskomplexität. Der Testcode ist normalerweise immer noch einfacher als der Kampfcode. Voraussetzungen, Aufrufen des Kampfcodes, Nachbedingungen - und so weiter für jeden Test. Der Code zum Erstellen der Umgebung ist komplizierter, erreicht aber immer noch nicht den Kampf. Auswahl optimaler Algorithmen, Entwurf komplexer Datenstrukturen, Aufbau von Klassenhierarchien - all dies wird normalerweise vom Testentwickler durchgeführt.
Die Erfahrung gewinnt langsamer . Die Vielfalt und Komplexität von Situationen, in die der Testentwickler fällt, ist viel geringer. Fließbandfehler, rote Tests, manchmal Dumps - dies ist der Hauptsatz, mit dem Sie normalerweise arbeiten müssen. Der Entwickler hat viel mehr Probleme: Er beginnt mit Verknüpfungs- und Baugruppenvarianten, geht weiter mit Störungen bei einem bestimmten Kunden und erstellten Dumps und endet mit der Suche nach Fehlern im Compiler und in Bibliotheken von Drittanbietern. Und nicht nur...
Ein wesentlicher Unterschied im Teststil bei Entwicklern. Normalerweise bevorzugen SDETs kompakte Ausdruckstests, mit denen Sie eine komplexe Umgebung in nur wenigen Zeilen erstellen können, und atomare Überprüfungen im Stil sind gleich / ungleich (dh die Anforderung ist erfüllt oder nicht). Manchmal kommt es zu seinem DSL. Entwickler bevorzugen einfach Tests mit Feinabstimmung der Umgebung und zahlreichen Tests verschiedener Aspekte des Programmverhaltens, was zu mehrzeiligen Tests führt. Manchmal kommt es zum Kopieren und Einfügen (was selbst die besten Entwickler in diesem Fall nicht als Sünde betrachten). Hier können Sie lange diskutieren, wie es am besten ist oder sogar einen separaten Artikel schreiben. Tatsache ist jedoch, dass ein Entwickler, der versucht, SDET-Tests zu ändern (oder umgekehrt), häufig zu langen und ineffektiven Diskussionen führt.
Unten ist die "Note". Vielleicht aufgrund von einfacherem Code und weniger Verantwortung, aber letztendlich nicht wichtig. Es ist einfach normalerweise so.
Es ist schwieriger, eine neue Position einzunehmen. SDET könnte die Frage auf die Stirn bekommen: Sie haben so lange Tests geschrieben, das heißt, Sie haben gerade Funktionen aufgerufen und die Ergebnisse verglichen - können Sie echten Code schreiben? Kennen Sie alle Fallstricke der Sprache? Haben Sie komplexe Probleme gelöst? Mussten Sie verzierte Käfer oder Müllkippen zerlegen? Gibt es Erfahrungen mit Multithreading? Haben Sie doch Ambitionen?

Zusammenfassung 2

Als eine Person, die viele Jahre als Entwickler gearbeitet hat, dann mehrere Jahre zu SDETs gegangen ist und dann wieder zur Entwicklung zurückgekehrt ist, kann ich Folgendes sagen.

Ich empfehle dringend, ein SDET für mindestens ein oder zwei Jahre auszugeben. Dies ist eine sehr lohnende Erfahrung für jeden Entwickler. Aber dort zu bleiben, lohnt sich meiner Meinung nach nicht.

Was sind Komponententests und wie ist es, ein SDET zu sein?