Beste Weg, um zu testen, Befehlszeilen-tools?

Ich habe eine große Sammlung von Kommandozeilen-utilities, das sind wir schreiben Sie uns und verwenden Sie Häufig. Im moment testen ist sehr mühsam und daher haben wir nicht so viel testen, wie wir irgendetwas zu.

Frage ich mich, ob jemand vorschlagen kann, gute Techniken oder tools für einen guten job machen, der diese Art der Sache.

Dies ist UNIX

  • Verwenden Sie oder schreibt/produziert die Befehlszeilen-Dienstprogramme?
InformationsquelleAutor Tom Duckering | 2008-12-09
  1. 5

    Aruba ist ein Gurke Erweiterung zum testen von Kommandozeilen-Anwendungen in einer beliebigen Programmiersprache geschrieben.

    Um es zu verwenden, benötigen Sie ruby um die tests auszuführen, aber der Zweck aruba ist eine Bibliothek von vordefinierten Schritt-Definitionen, so dass Sie nicht brauchen, um zu schreiben von ruby-code, um ein brauchbares test-suite. (Obwohl an einem gewissen Punkt werden Sie wahrscheinlich wollen, um zu schreiben, etwas in ruby zu machen, ein paar benutzerdefinierte Schritte.)

    Können Sie sehen, ein anspruchsvolles Beispiel für eine Kommandozeilen-tool getestet, mit dem aruba-hier: jingweno/gh

    InformationsquelleAutor avh
  2. 8

    Können Sie tests schreiben, die Aussehen wie eine interaktive shell-session mit Cram. Es hat flexible test-Spezifikation-format, können Sie match-Ausgang mit Perl-regex oder-shell-artige wildcards. Stopfen wird replay Befehle aus dem test, vergleichen die Ausgabe der Referenz-und der Berichts-Unterschiede.

    InformationsquelleAutor Mr. Deathless
  3. 7

    Empfehle ich die Strukturierung Ihrer Kommandozeilen-tool den code so, dass das Befehlszeilen-Dienstprogramm ist ein client, um eine Bibliothek von Funktionen und/oder Klassen.

    Anstatt einfach mit std::cout zu Ausgabe, haben die Bibliotheken-Funktion nehmen Sie eine ostream-Referenz, die standardmäßig auf std::cout. Wenn Sie testen, stellen Sie eine std::stringstream zum sammeln der Ausgabe.

    Schließlich, vergleichen Sie einfach das Dienstprogramm Ausgabe mit erwarteten Ergebnissen mit Ihrer Lieblings-unit-testing-framework.

    (Ich entschuldige mich für die C++ - spezifischen Beispiel... ich bin mir sicher, dass es Möglichkeiten gibt, die ähnliche Dinge tun in anderen Sprachen auch).

    InformationsquelleAutor paxos1977
  4. 3

    Sollten Sie in der Lage sein, Sie zu nennen von einem shell-Skript (batch-Datei, die auf MS-Betriebssystemen), leiten Sie die Ausgabe in eine Datei, dann Scannen Sie die Datei programmgesteuert, um sicherzustellen, dass es die richtige Ausgabe. Ich bin mir nicht bewusst, ein Test-framework zur Automatisierung in diesem für Sie, aber es sollte ziemlich gerade nach vorne zu setzen, es selbst.

    • Ja - ich hatte gehofft, dass jemand vielleicht bewusst sein, ein framework oder tool. Ich dachte darüber nach, zu klopfen, man selbst als Ihr Recht, es würde nicht allzu schwierig sein. Cheers. Tom
    InformationsquelleAutor Bill the Lizard
  5. 2

    Habe ich ein wenig von diesem (eine laaaange Zeit her, hehe) mit Erwarten um zu überprüfen, dass das, was passiert war, was ich, ähm, erwartet

    InformationsquelleAutor LenW
  6. 1

    Fledermäuse (Bash Automated Testing System) von Sam Stephenson. Es ist winzig, geschrieben rein in die Schale und hat eine schöne Reihe von Funktionen.

    Bisher vorgeschlagenen Aruba sieht interessant aus, aber in einigen Fällen kann es ruhig ein übermaß in Bezug auf die Abhängigkeiten (ruby, Gurke)

    InformationsquelleAutor Hugo
  7. 0

    Dazu können Sie aus einer batch-Datei oder der windows scripting host.

    Aber ich verspreche, verwenden Sie einen task-scheduler wie (http://www.splinterware.com/products/wincron.htm) oder anderen free/professional software.

    Dort können Sie einfach kopieren/einfügen der Kommandozeilen-Parameter, die man variieren, wenn Sie wollen, testen Sie Ihre software für die über viele 100 mal?!

    InformationsquelleAutor berlindev
  8. 0

    Könnten Sie perl mit Test::mehr Bibliothek, die bietet einen tollen Rahmen für die Tests CLIs.
    Obwohl in Erster Linie entwickelt für unit-Tests, könnte man es verlängern, um zu testen, Benutzer-workflows.

    Einige der Methoden:

     # Various ways to say "ok"
  ok($got eq $expected, $test_name);
  is  ($got, $expected, $test_name);
  isnt($got, $expected, $test_name);

  # Rather than print STDERR "# here's what went wrong\n"
  diag("here's what went wrong");

  like  ($got, qr/expected/, $test_name);
  unlike($got, qr/expected/, $test_name);

  cmp_ok($got, '==', $expected, $test_name);

    command-lineautomationTestperl-Test

    InformationsquelleAutor Venkat
  9. 0

    Habe ich ein tool entwickelt, das "Genau"
    https://github.com/emilkarlen/exactly

    Führt er das Ding zum testen in ein temporäres sandbox-Verzeichnis.
    Die README enthält eine Reihe von Beispielen.

    Test des hypotethical Programm "klassifizieren-Dateien-durch-Umzug-um-angemessene-dir" kann wie folgt Aussehen:

    [setup]

dir input
dir output/good
dir output/bad

file input/a.txt = <<EOF
GOOD contents
EOF

file input/b.txt = <<EOF
bad contents
EOF

[act]

classify-files-by-moving-to-appropriate-dir GOOD input/output/

[assert]

dir-contents input empty

exists output/good/a.txt : type file
dir-contents output/good num-files == 1

exists output/bad/b.txt : type file
dir-contents output/bad num-files == 1
    InformationsquelleAutor Emil Karlén
Schreibe einen Kommentar