Ankündigung

Einklappen
Keine Ankündigung bisher.

TDD in einem SSH Tool

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #31
    Hallo BlackScorp,

    wenn du einen Unit-Test von externen APIs abhängig machst, ist es streng genommen kein Unit-Test mehr. Prinzipiell musst du dir deshalb auch keine Testumgebung bauen, mit der das funktioniert, sondern die SSH-Verbindung so abstrahieren, dass es gar keine "echte" Verbindung gibt, sondern die Verbindung nur simuliert und die Rückgaben fix sind.


    Auch auf die Gefahr hin, dass ich deine Skills stark unterschätze (schlag mich nicht, wenn ich dir jetzt hier mein spärliches Grundlagenwissen präsentiere), ich halte Mocks / Stubs da für die richtige Technologie (https://phpunit.de/manual/current/en...l#test-doubles). Ein Beispiel (Code ist gänzlich ungetestet):

    PHP-Code:
    class SshTest {
        private 
    $ssh;
        public function 
    setUp() {
            
    $this->ssh $this->getMock('Ssh', array('execute'));
        }
        
        public function 
    testExecute() {
            
    $this->ssh->expects($this->any())
                 ->
    method('execute')
                 ->
    will($this->returnValue('andreas'));
                 
            
    $this->ssh->execute("whoami");
        }
    }

    class 
    Ssh {
        private 
    $session;
        
    // ...
        
    public function execute($command) {
            return 
    ssh2_exec($this->session $command);
        }

    Problem ist natürlich, dass du so kaum sagen kannst, ob dein Code auch in einer Produktivumgebung funktioniert. Um den Aufwand möglichst gering zu halten, würde ich dafür Akzeptanztests schreiben (auch mit PHPUnit), die NUR lokal bei dir ausgeführt werden und davon ausgehen, dass die Akzeptanztests aussagekräftig genug sind, dass es auf anderen Systemen auch funktioniert.

    Die Lokal ausgeführten Akzeptanztests kannst du ja so auslegen, dass du lokal mehrere Beispielumgebungen nachbildest (z.B. mit VMs), die tatsächlich recht gut gewährleisten, dass dein Code sauber funktioniert.
    Tutorials zum Thema Technik:
    https://pilabor.com
    https://www.fynder.de

    Kommentar


    • #32
      Hallo Andreas

      endlich einer der das Problem verstanden hat , wenn ich dinge Mocke kann es dennoch sein dass es in der Realen Welt nicht laufen wird


      Aber das ist ein guter hinweis, ich könnte Implementation Tests nur Lokal ausführen während ich andere Tests dann auf Travis laufen lasse.

      Ich dachte nur, vielleicht gibt es eine schönere variante :/
      apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

      Kommentar


      • #33
        Zum Thema, Unit-, Integrations- und Akzeptanztests könnte evtl. auch folgendes Buch interessant sein

        http://www.amazon.de/Softwarequalit%.../dp/3446435395

        insbesondere Kapitel 14 „Testen von serviceorientierten APIs“ setzt sich mit der o. beschriebenen Problematik ausführlich auseinander.

        vg
        jack
        -

        Kommentar


        • #34
          endlich einer der das Problem verstanden hat , wenn ich dinge Mocke kann es dennoch sein dass es in der Realen Welt nicht laufen wird
          Ich habs dir glaub ich schonmal im webgamers chat geschickt, hier jetzt nochmal:

          http://thephp.cc/dates/2012/webexpop...best-practices <-- Folie 27
          A real unit test verifies the behavior of a single code unit isolated from its dependencies
          Ich denke, dass das alles klar stellt.

          Falls du dennoch auch auf travis alles mittesten willst (sonst kannste ja auch nur eine testsuite auf travis laufen lassen und die, die vagrant braucht eben nicht) könnte das (https://github.com/travis-ci/travis-cookbooks) vielleicht helfen.

          LG
          https://github.com/Ma27
          Javascript Logic is funny:
          [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

          Kommentar


          • #35
            Ok, ich habe das Problem auch nicht verstanden, da ich den Bezug zum Server falsch verstanden habe. Da bin ich aber grundsätzlich bei Andreas und möchte hinzufügen, dass Mocking in diesem Fall ausreichen sollte.

            Mal davon abgesehen, dass die Aufgabe noch etwas bereit hält, was deinen Fall komplexer macht als ich das gerade überblicke, ist dein Ansatz aber nicht so lückenlos, als eine umfassende Mockingumgebung.

            Der Grund ist, dass deine VM-Umgebung nicht nur korrekt auf Befehle reagieren müsste, sondern auch jeden denkbaren Fehlerfall durchspielen müsste (Festplatte voll, System-Software nach Update kaputt/verhält sich anders, Verbindungsabbruch, etc). Da kommt im schlimmsten Fall einiges zusammen. Und hier glaube ich, dass eine Mocking-Umgebung eben all deine Fälle besser abdecken könnte, als eine echte VM.

            Die echte VM ist dabei aber nicht aus dem Spiel. Du kannst jederzeit (DI sei dank) die Mock-Verbindung gegen eine echte ersetzen und schauen, ob die Mock-Objekte noch die Realität abbilden (wenn nicht, werden sie angepasst). Mock-basierte Tests auch wesentlich schneller durchlaufen.

            Kommentar


            • #36
              Damit meine Annahme funktioniert muss gegeben sein, dass sich die VM-Umgebung in aller Regel immer identisch verhält und deine Tests sich ändernden Code immer wieder gegen diese an sich stabile Api fahren. Jede Änderung an Remoteaufrufen sollte also einmal gegen ein echtes System getestet werden. Der Rest deiner Applikation muss das nicht.

              Kommentar

              Lädt...
              X