Mein Team findet in den Komponententests, die wir schreiben, immer mehr Wert. Wir testen die Datenzugriffsschichten unserer Anwendungen im Allgemeinen nicht Unit-Test, da sie keine "Logik" enthalten. Meiner Erfahrung nach sind wir auf erhebliche Leistungsprobleme und nicht reproduzierbare Fehler gestoßen, weil Entwickler Unit-Tests geschrieben haben, die mit Live-Datenbanken (oder Webservices) kommunizieren, und dadurch immer mehr Entwickler Mocks erstellen, die Daten an diese liefern Komponententests.
Bei diesem Ansatz wurde die Geschwindigkeit der Tests erhöht und das Testen isoliert, anstatt die Verbindung / Abfrage gleichzeitig zu testen. Ich frage mich, ob das vernünftig klingt, um als Kodierungsstandard durchzusetzen. Was sind die Vor- / Nachteile in Bezug auf Unit-Testing Live-Datenbanken / Webservices, die ich vermisse?
Die Datenbank- und Webservice-Teile Ihrer Anwendung sollten ebenfalls getestet werden, aber per Definition handelt es sich nicht um Komponententests, sondern um Integrationstests. Diese Tests würden von Ihren Komponententests getrennt sein und seltener ausgeführt werden, bieten jedoch eine sehr wertvolle Früherkennung von Defekten.
Im Allgemeinen sehe ich einen Komponententest als etwas an, das eine einzelne Klasse oder ein einzelnes Modul isoliert testet . Als solche versuche ich zu vermeiden, dass Komponententests über Live-Systeme oder externe Ressourcen bekannt sind - ich tendiere dazu, solche Abhängigkeiten in Komponententests zu vermeiden - oder verspotte sie.
Integrationstests sind eine andere Geschichte. Ein Integrationstest sollte
In einigen Fällen ist es wünschenswert, die Dienste zu simulieren, die für einen Integrationstest erforderlich sind. Aber wenn möglich, versuche ich dies zu vermeiden, weil ich der Simulation nicht traue, das Verhalten der realen Sache widerzuspiegeln. Für mich sollte ein Integrationstest tatsächlich die Integration von Komponenten in ein System testen.
Komponententests sollten nicht mit Live-Daten durchgeführt werden, Punkt.
Auch wenn Sie mit Integrationstests beginnen möchten, sollten Sie dies nicht mit Live-Daten starten.
Ein beginnender Integrationstest sollte immer entweder mit Dev-Daten oder Mockup-Daten durchgeführt werden. Ein bevorzugtes Verfahren wäre ein Dev-System, das aus Live-Daten veröffentlicht hat, oder Sie verwenden sql-Skripte, um einen vollständigen Satz von Daten zu generieren, mit denen Sie testen können.
IMO Sie vermissen wahrscheinlich, dass wenn Sie Datenbanken / WS für den Test verwenden, dies kein Komponententest ist, sondern ein Integrationstest.
Jeder Build-Validierungstest sollte so vollständig wie möglich sein. Wenn Sie einen Funktionsaufruf haben, der externe Ressourcen weiterleitet, müssen Sie sicherstellen, dass sich das gesamte System ordnungsgemäß verhält.
Das Problem mit spezifischen Komponententests für Funktionen, die eine Verbindung zu einer Datenbank herstellen, kann problematisch sein, da diese Funktionen Nebenwirkungen haben können, z. B. Daten einfügen. Diese Nebenwirkungen können dazu führen, dass sich die Rückgabewerte ändern.
Nach meiner Erfahrung sollten Tests auf mehreren Ebenen durchgeführt werden:
Jeder dieser Tests hat seine Nützlichkeit.
Es tut mir leid, aber viele Entwickler vermissen die Tatsache, dass Sie auch die Datenbank testen müssen. Ich kann der Verspottung der Verbindung zwischen Klasse "A" und der Datenbank zustimmen, aber irgendwann werden Sie eine Klasse erstellen, die einige Datenzugriffstechnologien (z. B. ADO.NET) verwendet, und Sie müssen das testen es funktioniert tatsächlich.
Wenn Sie nun diese Tests klein und fokussiert halten, können Sie leichter Nebenwirkungen verhindern und die richtigen Anfangsbedingungen für die Datenbank sicherstellen. Aber Tatsache ist, dass Sie solchen Code testen müssen, oder Ihre ordnungsgemäß getestete Geschäftslogik wird mit schlechten Daten enden, mit denen Sie arbeiten können.
Tags und Links .net unit-testing continuous-integration coding-style