Haftungsausschluss: Functional Testing wird nachfolgend synonym mit System Testing verwendet. Das Fehlen einer formalisierten Spezifikation für die meisten Fabric-Projekte macht die Unterscheidung strittig. Außerdem kann es passieren, dass ich zwischen den Begriffen "Functional Testing" und "Integration Testing" leger werde, da die Grenze zwischen ihnen mit jeder Konfigurationsverwaltungssoftware verwischt.

Lokaler Funktionstest für Fabric ist schwer (oder unmöglich)

Ich bin mir ziemlich sicher, dass es nicht möglich ist, Funktionstests durchzuführen, ohne entweder eine VM zu erstellen, die Sie als eine Ihrer Einschränkungen angeben, oder extrem ausgiebig zu spotten (was Ihre Testsuite von Natur aus fragil).

Betrachten Sie die folgende einfache Funktion:

Wenn Sie eine Aufgabe haben, die agnostic_install_lsb aufruft, wie können Sie Funktionstests für eine lokale Box durchführen?

Sie können Komponententests durchführen, indem Sie die Aufrufe von run , local und sudo mockern, aber nicht viel in Bezug auf Integrationstests auf höherer Ebene. Wenn Sie bereit sind, mit einfachen Komponententests zufrieden zu sein, brauchen Sie nicht unbedingt ein Test-Framework über mock und nose hinaus, da alle Unit-Tests unter streng kontrollierten Bedingungen ablaufen.

Wie du die Verspottung machen würdest

Sie konnten die sudo verspotten local und run Funktionen ihre Befehle auf einen Satz von StringIO s oder Dateien zu protokollieren, aber, es sei denn, es ist etwas klug, dass ich fehle, würden Sie auch müssen ihre Rückgabewerte sehr sorgfältig verspotten. Um weiterhin die Dinge zu sagen, die Sie wahrscheinlich bereits kennen, müssten Ihre Mocks entweder die Fabric-Kontextmanager (hart) kennen oder Sie müssten alle von Ihnen verwendeten Kontext-Manager vortäuschen (immer noch hart, aber nicht so schlecht) ).

Wenn Sie diesen Pfad durchgehen möchten, ist es sicherer und einfacher, eine Testklasse zu erstellen, deren Setup Mocks für alle Kontextmanager, run , sudo und alle anderen Teile von Fabric instanziiert die Sie verwenden, anstatt zu versuchen, eine minimale Menge an Verspottung pro Test zu machen. An diesem Punkt haben Sie ein etwas generisches Testframework für Fabric erstellt, und Sie sollten es wahrscheinlich auf PyPi als ... "mabric" teilen?

Ich behaupte, dass dies in den meisten Fällen nicht viel nutzen würde, da Ihre Tests sich nicht darum kümmern, wie ein Lauf ausgeführt wird, und nicht nur, was am Ende getan wird. Das Umschalten eines Befehls auf sudo('echo "cthulhu" > /etc/hostname') von run('echo "cthulhu" | sudo tee /etc/hostname') sollte die Tests nicht unterbrechen, und es ist schwer zu sehen, wie dies mit einfachen Mocks erreicht werden kann. Dies liegt daran, dass wir begonnen haben, die Grenze zwischen Funktions- und Komponententests zu verwischen, und diese Art von elementarem Mocking ist ein Versuch, Komponententestmethoden auf Funktionstests anzuwenden.

Das Testen der Configuration Management Software auf VMs ist eine etablierte Praxis

Ich möchte Sie dringend bitten, noch einmal zu überdenken, wie sehr Sie VMs für Ihre Funktionstests vermeiden möchten. Dies ist die allgemein anerkannte Praxis für Chef-Tests, die viele der gleichen Herausforderungen konfrontiert.

Wenn Sie Bedenken hinsichtlich der Automatisierung haben, kann Vagrant die Erstellung von VMs aus einer Vorlage sehr vereinfachen. Ich habe sogar gehört, dass es eine gute Vagrant / Docker-Integration gibt, wenn Sie ein Docker-Fan sind. Der einzige Nachteil ist, dass Vagrant VMWare Workstation ($$$) benötigt, wenn Sie ein VMWare-Fan sind. Alternativ können Sie einfach Vagrant mit Virtualbox kostenlos verwenden.

Wenn Sie in einer Cloud-Umgebung wie AWS arbeiten, haben Sie sogar die Möglichkeit, neue VMs mit denselben Basisimages wie Ihre Produktionsserver zu starten, um Ihre Tests durchzuführen. Ein großer Nachteil ist natürlich, dass dies Geld kostet. Es ist jedoch kein signifikanter Anteil Ihrer Kosten, wenn Sie Ihren vollständigen Software-Stack bereits in einer öffentlichen Cloud ausführen, da die Testserver nur für ein paar Stunden pro Monat verfügbar sind.

Kurz gesagt, gibt es eine Reihe von Möglichkeiten, das Problem der vollständigen Funktionsüberprüfung von VMs zu lösen. Dies ist eine bewährte Methode für andere Konfigurationsmanagement-Software.

Wenn Sie Vagrant (o.ä.) nicht verwenden, behalten Sie eine Suite lokal ausführbarer Einheitentests

Eines der offensichtlichen Probleme bei der Ausführung Ihrer Tests hängt von der Ausführung einer VM ab. Sie erschwert das Testen für Entwickler. Dies gilt insbesondere für das iterierte Testen mit einer lokalen Codeversion, wie es einige Projekte (z. B. Web-UI-Entwickler) erfordern.

Wenn Sie Vagrant + Virtualbox, Docker (oder Raw LXC) oder eine ähnliche Lösung für Ihre Testvirtualisierung verwenden, sind lokale Tests nicht sehr teuer. Mit diesen Lösungen können frische VMs in weniger als zehn Minuten auf billiger Laptop-Hardware installiert werden. Bei besonders schnellen Iterationen können Sie möglicherweise mehrmals für dieselbe VM testen (und sie dann für einen letzten Testlauf durch eine neue ersetzen).

Wenn Sie jedoch Ihre Virtualisierung in einer öffentlichen Cloud oder einer ähnlichen Umgebung durchführen, in der zu viele Tests auf Ihren VMs kostspielig sind, sollten Sie Ihre Tests in eine umfangreiche Unit-Testsuite, die lokal ausgeführt werden kann, und Integrations- oder Systemtests einteilen benötige die VM. Diese separate Testreihe ermöglicht die Entwicklung ohne die vollständige Testsuite und läuft bei fortschreitender Entwicklung gegen die Komponententests. Vor dem Zusammenführen / Versenden / Abmelden von Änderungen sollten sie dann gegen die Funktionstests auf einer VM ausgeführt werden.

Letztendlich sollte nichts in Ihre Codebase gelangen, die die funktionalen Tests nicht bestanden hat, aber Sie sollten versuchen, so weit wie möglich die vollständige Codeabdeckung für eine solche Suite von Komponententests zu erreichen. Je mehr Sie tun können, um das Vertrauen zu stärken, das Ihnen Ihre Komponententests geben, desto besser, da die Anzahl der fehlerhaften (und möglicherweise kostspieligen) Läufe Ihrer Systemtests reduziert wird.