Test-SW für C-Prog in Python?

Post Reply
Message
Author
Hank
Posts: 18
Joined: 25. Jun 2007 15:16

Test-SW für C-Prog in Python?

#1 Post by Hank »

Moin!

Ist es möglich, für ein vorhandenes C-Programm ein Test-Programm in Python zu schreiben? Im Prinzip möchte ich direkt aus Python heraus eine C-Funktion mit ihren Parametern aufrufen und eine Tabelle mit den jeweiligen Rückgabewerten/Ergebnissen erstellen.

Weiss jemand eine Quelle, wo dies beschrieben ist?

Vielen Dank,
Hank

Hank
Posts: 18
Joined: 25. Jun 2007 15:16

#2 Post by Hank »

Falls es mit Python evtl. nicht gehen sollte, würde es evtl mit Perl funktionieren?
Kennt sich jemand damit aus?

Gruß
Hank

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#3 Post by Janka »

Mit einem Programm geht das nicht ohne weiteres (da reinzupfuschen ist eine Debugger-Funktionalität), höchstens mit einer shared library könnte man was einfaches basteln.

Hast du den Quellcode des Programmes vorliegen?

Wenn dir statt python oder perl auch tcl zusagt, guck mal nach "critcl". Das kompiliert in Tcl-Quelltext eingebettenen C-Quelltext als .so und baut gleich noch ein passendes Interface dazu. Damit kann man kurze (oder auch lange) C-Stücken einfach so in Tcl einbetten.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

Hank
Posts: 18
Joined: 25. Jun 2007 15:16

#4 Post by Hank »

Hallo Janka! Danke für deinen Tip!

Den Quellcode hab ich vorliegen ja.

Critcl hab ich mir nur kurz angeschaut, bin da aber auf Anhieb noch nicht durchgestiegen, wie das Prinzip ist, aber ich werde nochmal einen Blick drauf werfen.

Es gibt ja auch Unit-Test-Programme wie z.B. CUnit und autounit, aber die scheinen mir für mein Vorhaben eher zu komplex zu sein.

Grad kam mir die Idee ob der folgende Ansatz nicht auch einen Versuch wert wäre:
1) Die zu testende Funktion wird in einem einfachen main()-Programm eingebunden.
2) Die Kommandozeilen-Parameter dieses Programms werden an die zu testende Funktion weitergereicht.
3) Test-Fälle mit entsprechender Parameterkonstellation können mit Python/Perl/Bash etc geschrieben werden.
4) Die Ergebnisse der Tests werden entweder auf die Konsole geschrieben oder in eine Datei.
5) Weitere Automatisierung könnte mit make erfolgen. Z.B automatischer Test _aller_ zu testenden Funktionen mit einem make-Aufruf.

Hat jemand schonmal etwas Ähnliches versucht?
Gibt es vielleicht gute wie auch schlechte Erfahrungen mit solch einem Ansatz? Eventuell Probleme, die ich jetzt noch nicht beachte?

Bin für jeden Hinweis dankbar!

Hank

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#5 Post by Janka »

Dein einfacher Ansatz scheitert, wenn komplizierte Datenstrukturen übergeben werden. Dann braucht man einen komplizierten Wrapper, der die entsprechenden Strukturen aus den auf der Kommandozeile übergebenen Strings erzeugt.

Willst du nur eine ganz bestimmte Funktion testen, oder mehr allgemein ein Testprogramm für alle eure Quellcodes?

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

Hank
Posts: 18
Joined: 25. Jun 2007 15:16

#6 Post by Hank »

Das mit dem Wrapper ist richtig, ist aber eigentlich auch so gewollt. Ich denke so sehr viel Mehr-Arbeit dürfte das nicht werden.

Ich stehe momentan am Anfang meiner Diplomarbeit, in dessen Rahmen ich auch einiges an Software zu entwickeln habe. Da das ganze System an sich schon relativ komplex ist, möchte ich mich einfach so wenig wie möglich mit den einfacheren Fehlern herumärgern. Also im Grunde werden es mehrere Module, die in ein Trägerprogramm eingebunden werden, sowohl das Trägerprogramm als auch das Modul stellen dann entsprechende Schnittstellen bereit, sodass eine bidirektionale Kommunikation erfolgt.

Meine Überlegung ist, sich zu jeder Funktion ein paar Testfälle auszudenken (positive und negative Funktionstests). Das Ganze möchte ich idealerweise soweit automatisiert haben, dass ein Testvorgang durch einen simplen Befehl gestartet wird, komplett durchläuft und mir entsprechende Ergebnisse auflistet, die ich mir dann durchsehe. Wenn ich in einem Programm, das schon getestet ist, einige Änderungen durchführe, bräuchte ich dann nur nochmal des Testdurchlauf starten, aber nicht alle Tests manuell durchführen.

Ein erhebliches Problem sehe ich aber momentan bei externen Schnittstellen, das Programm wird z.B. auch auf Hardware zugreifen, sowie auf externe Eingabedaten von anderen Rechnern angewiesen sein. Aber vielleicht ist mir ja schon sehr damit geholfen, wenn ich eine gute Möglichkeit habe, die kleineren lokalen Funktionen zu testen, die nicht auf externe Kommunikation angewiesen sind. Um einen manuellen Systemtest, ob alles funktioniert, werde ich natürlich ohnehin nicht herumkommen.

Ich möchte nur nicht so viel Zeit mit Debugging der eigentlich einfachen Funktionen verschwenden. Dafür darf aber natürlich das Aufsetzen der Testumgebung auch nicht zu aufwändig sein... ;-)

Hank

Gast

#7 Post by Gast »

Hallo

Ein Grundsatz in der modernen Software Entwicklung lautet: Schreibe mindestens so viel Testcode wie Produktivcode. Manche gehen sogar soweit, dass sie das Konzept des 'Test driven development' anwenden.

Testen ist nicht zeitaufwändig wenn man von Anfang an damit beginnt.

Es gibt verschiedene Arten von Tests. Black Box (Modul ohne innere Kenntnis wird getestet) und White Box (Modul mit Kenntnis der inneren Strukur wird getestet). Du solltest dir zuerst Gedanken darüber machen, was du testen möchtest.
Wenn dein Design sauber ist (dh eine geringe Anzahl von Abhängigkeiten aufweist) kannst du Tests so schreiben, dass du ein Modul nimmst, Eingabewerte übergibst und die Ausgabe überprüfst (Modul kann hier verschiedenes sein).
Das Ganze kannst du mit einfachem C-Code realisieren.

Wie auch immer, ich empfehle dir ein Testframework, auch wenn es ein paar Stunden Einarbeitungszeit verlangt. Am Ende bist du schneller und kannst etwas sauberes abliefern.

hth

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#8 Post by Janka »

Gast wrote:Hallo
Ein Grundsatz in der modernen Software Entwicklung lautet: Schreibe mindestens so viel Testcode wie Produktivcode.
Ja. Das ist zumindest wünschenwert. Leider bezahlt das Testen einem niemand. Die Kunden können üblicherweise ein ausgereiftes, gut getestetes Produkt nicht vom Wackelkandidaten der Konkurrenz unterscheiden, der Dank Bananen-Taktik (Produkt reift beim Kunden) erstens schneller am Markt ist und zweitens kostenlose Nachbesserungen verspricht.

Die allermeisten Kunden wollen lieber ein ausreichend funktionierendes Produkt gestern als ein hervorragend funktionierendes Produkt irgendwann.

Die eigene Verkaufsabteilung ist der Feind jeder Qualität. Die des Konkurrenten legt nur noch ein paar Scheite mehr auf Feuer.

Manche gehen sogar soweit, dass sie das Konzept des 'Test driven development' anwenden.
Das wird gemacht, wenn einem der Kunde das bezahlt. Zum Beispiel im Bahn- oder Flugbereich, wo Sicherheitsmängel die wirtschaftliche Existenz des Kunden in Gefahr bringen können.

Testen ist nicht zeitaufwändig wenn man von Anfang an damit beginnt.

Es gibt verschiedene Arten von Tests. Black Box (Modul ohne innere Kenntnis wird getestet) und White Box (Modul mit Kenntnis der inneren Strukur wird getestet). Du solltest dir zuerst Gedanken darüber machen, was du testen möchtest.
Wenn dein Design sauber ist (dh eine geringe Anzahl von Abhängigkeiten aufweist) kannst du Tests so schreiben, dass du ein Modul nimmst, Eingabewerte übergibst und die Ausgabe überprüfst (Modul kann hier verschiedenes sein).
Das Ganze kannst du mit einfachem C-Code realisieren.
Wichtig: Den Test sollte immer ein anderer Programmierer erstellen als das Modul selbst. Sonst ist die Gefahr gegeben, dass man bestimmte systematische Fehler zweimal übersieht.
Wie auch immer, ich empfehle dir ein Testframework, auch wenn es ein paar Stunden Einarbeitungszeit verlangt. Am Ende bist du schneller und kannst etwas sauberes abliefern.
Empfehle ich ebenfalls. Die Frameworks haben vor allem den Vorteil, dass man das Testen tatsächlich an jemanden Auslagern kann, der den lieben langen Tag nix anderes macht, als anhand der Spezifikation Testfälle zu schreiben, die das Programm dann auch erfüllen muss.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

Post Reply