Was ist der beste Weg zum Testen von Code-Pfaden, die einen fehlgeschlagenen malloc() beinhalten? In den meisten Fällen ist es wahrscheinlich egal, weil Sie etwas wie
Aber in einigen Fällen haben Sie andere Wahlmöglichkeiten als zu sterben, weil Sie etwas zusätzliches Material für das Caching oder was auch immer zugewiesen haben, und Sie können diese Erinnerung zurückgewinnen.
In solchen Fällen, in denen Sie versuchen können, sich von einem fehlgeschlagenen malloc() zu erholen, tun Sie etwas Schwieriges und Fehlerhaftes in einem Code-Pfad, der ziemlich ungewöhnlich ist, was das Testen besonders wichtig macht. Wie gehst du eigentlich dazu?
Ich sah eine kühle Lösung für dieses Problem, die mir von S. Paavolainen präsentiert wurde. Die Idee ist, den Standard malloc() , den Sie nur in der Linker tun können, durch einen benutzerdefinierten Zuordner,
malloc() aufruft
NULL zurück
Dann führen Sie einfach Ihren Komponententest viele Male aus: Dieses System zählt automatisch durch verschiedene Steuerpfade zu malloc() failure und ist viel effizienter und zuverlässiger als z.B. zufälliges Testen.
Ich schlage vor, eine spezielle Funktion für Ihren speziellen malloc-Code zu erstellen, von dem Sie annehmen, dass er fehlschlagen könnte und Sie elegant damit umgehen könnten. Zum Beispiel:
%Vor%Dann könntest du dieses schlaue Geschäft hier testen, indem du einige schlechte Werte für Bytes eingibst. Sie könnten dies in eine separate Bibliothek stellen und eine Scheinbibliothek erstellen, die sich speziell für das Testen der Funktionen, die diese aufrufen, verhält.
Das ist ein bisschen eklig, aber wenn Sie Unit-Tests wirklich wollen, könnten Sie es mit #ifdefs machen:
%Vor%Leider müssten Sie mit dieser Lösung viel neu kompilieren.
Wenn Sie Linux verwenden, können Sie auch Ihren Code unter Speicherdruck ausführen, indem Sie ulimit , aber sei vorsichtig.
In FreeBSD habe ich einmal einfach das C-Bibliotheksmodul malloc.o überlastet (die Symbole dort waren schwach) und die malloc () - Implementierung durch eine ersetzt, deren Wahrscheinlichkeit, fehlzuschlagen, kontrolliert wurde. Also habe ich mich statisch verbunden und begonnen, Tests durchzuführen. srandom () beendete das Bild mit einer kontrollierten Pseudozufallsfolge.
Sehen Sie sich auch hier für eine Reihe guter Tools an, die Sie meiner Meinung nach brauchen. Zumindest überlasten sie malloc () / free (), um Lecks zu verfolgen, so dass es als nützlicher Punkt erscheint, um etwas hinzuzufügen, was Sie wollen.
Tags und Links c unit-testing memory-management libc