Selbstbewusst entwickeln ohne echte Entwicklungsumgebung

Ich wurde kürzlich für ein Projekt engagiert, das die Arbeit mit und um mehrere "Enterprise" -Systeme von Drittanbietern umfasst. Aus meiner Sicht sind die astronomischen Kosten und der Aufwand für die Erstellung einer hinreichend getreuen Nachbildung der Produktionsumgebung äußerst gering.

Das ist natürlich nicht ideal. Auf der positiven Seite stelle ich mir vor, dass es Leute geben muss, die Software in solchen nicht replizierbaren Umgebungen sicher testen und bereitstellen, und ich kann wahrscheinlich in ihre Fußstapfen treten.

Wie gehen diejenigen, die effektiv mit solchen Situationen umgehen, damit um?

Dies passiert die ganze Zeit in der realen Welt. Ich kenne jemanden, der Apps schreibt, die gigantische landwirtschaftliche Gewächshäuser kontrollieren - Belüftung, Heizung, Feuchtigkeitskontrolle, wie Sie es nennen. Er hat kein "Testgewächshaus", aber er hat ein Simulatorprogramm, das von der Firma bereitgestellt wird, die die tatsächlichen Hardware-Systeme baut. Wenn der Code mit dem Simulator ordnungsgemäß funktioniert, wird davon ausgegangen, dass er mit der realen Ausrüstung ordnungsgemäß funktioniert. In seltenen Fällen stellt sich heraus, dass der Simulator falsch ist, aber das ist das Problem, mit dem sich das Unternehmen befasst, weil es nicht richtig simuliert.

Dies sind Situationen, in denen API-Dokumentation, Schnittstellenkontrolldokumente und Emulatoren von größter Bedeutung sind. In einem Unternehmen, für das ich zuvor gearbeitet habe, passierte dies tatsächlich. Dies passierte häufig innerhalb eines Projekts in bestimmten Integrationsphasen, in denen ein Segment fertig war, andere jedoch zurückblieben, an einem anderen Feature gearbeitet wurde oder aus einem anderen Grund nicht bereitgestellt werden konnten die neueste Version ihres Segments zu unserem Testsystem. Ja, wir hatten tatsächlich eine originalgetreue Nachbildung unserer Produktionsumgebung, die wir getestet haben. In der Praxis waren jedoch nie alle Segmente termingerecht einsatzbereit, sondern Schnittstellen wurden vor Beginn der Entwicklung vereinbart und gesperrt, und es wurden Emulatoren erstellt, die das Verhalten der anderen Segmente größtenteils nachahmen konnten.

Als weitere Antwort wurde angegeben, dass der Emulator die Durchführung der Tests vor der Bereitstellung ermöglicht. Ein guter Emulator; hängt jedoch von gut definierten Schnittstellen und Dokumentation ab.

Ich bin die ganze Zeit in solchen Situationen.

Sie müssen sicherlich nicht mit der gesamten Anwendung interagieren, sondern wahrscheinlich mit einigen Schnittstellen. Stellen Sie sicher, dass Sie die Schnittstellen bestätigt und detailliert dokumentiert haben, und richten Sie dann die Mocks dieser Schnittstellen nur ein, um zu überprüfen, ob der hinzugefügte / geänderte Code so funktioniert, wie Sie es beabsichtigt haben.

Sie können auch einen Hybrid machen. Versuchen Sie, die Teile zu replizieren, die Sie ziemlich einfach tun können, und "verbinden" Sie sich dann mit den realen Systemen (falls dies in Ihrer Situation möglich ist). Ich habe dies mit einigem Erfolg getan - in einigen Fällen, in denen meine Logik und die Serversoftware lokal ausgeführt wurden, ich aber dennoch eine Verbindung zum realen ERP-System hatte, um Abrufe usw. zu verifizieren. Nicht ideal, aber selten.

Wenn Sie nur über ein Produktionssystem verfügen, mit dem Sie arbeiten können - beachten Sie, dass Sie beim Einrichten eines Replikats nicht nur die eingesparte Entwicklungszeit zählen können, sondern auch das Geschäftsrisiko berücksichtigen müssen, wenn Sie weitgehend ungeprüften Code mit aktiven Geschäftsdaten verwenden. Ihr Code ist weniger zuverlässig als Code, der anhand eines Replikats getestet wurde. Können die Systeme für einige Zeit außer Betrieb sein? Können sie im Falle einer Datenbeschädigung wiederhergestellt werden? Wie viel kostet das?

Eine bewährte Vorgehensweise in Unternehmen besteht darin, ein Replikat (oder mehrere) der Produktion zu dem Zeitpunkt zu erstellen, an dem die Produktionsumgebung eingerichtet wird. In diesem Moment werden die zusätzlichen Kosten nicht so groß sein.

Unser System funktioniert mit einer Reihe großer externer Systeme. Wir kombinieren die folgenden Ansätze beim Testen, wenn wir kein vollständiges End-to-End-Setup haben:

• Reale Daten aufzeichnen und wiedergeben.Erfassen Sie reale Daten (Anfragen / Antworten von realen externen Systemen), parametrieren Sie diese bei Bedarf und spielen Sie sie ab
• Bauen oder kaufen Sie einen Simulator , der als externes System fungiert
• DSL zur Testdatengenerierung. Schreiben Sie für datengesteuerte Systeme High-Level-DSL zum Generieren von Testdaten.