Muss jeder Testfall am Ende seine Operation rückgängig machen?

Question

Die Frage mag ein wenig vage, aber hier ist ein Beispiel dessen, was ich (Pseudo-Code) wissen wollen:

//start test-case for CreateObject function 
{ 
// initialization of parameters 
MyObject *obj = CreateObject(); 
// test results 
} 
//end test-case for CreateObject function 

Ist es in diesem Fall notwendig, auch den Speicher freizugeben, indem „DestroyObject“ Funktion aufrufen? [das ist der Sonderfall, der diese Frage hervorbrachte]

Meine persönliche Meinung wäre nein, dass ich die Funktion nicht rückgängig machen sollte, aber wenn viele Tests durchgeführt würden, könnte ich ohne Speicher/Ressourcen bleiben für diese Testsuite (wird wahrscheinlich nicht passieren, aber ...).

Was denkst du? In diesem Fall und auch in einem allgemeinen Fall.

Danke,

Iulian

Answer 1

In diesem Fall sollten Sie den Speicher Ihres Testfall zugeordnet ausplanen. Auf diese Weise können Sie ein Tool verwenden, mit dem Sie Ihre Tests ausführen und bestätigen können, dass kein Speicher verloren gegangen ist. Wenn Sie Ihren Testcode auslecken lassen, bedeutet dies, dass dies fehlschlagen würde und Sie nicht mit Sicherheit sagen können, dass sich das Leck im Test und nicht in Ihrem Produktionscode befindet.

Was die allgemeine Situation betrifft, sollten die Tests sauber machen, was sie getan haben. Bei den meisten Unit-Test-Frameworks können Sie hierfür eine tearDown() -Methode implementieren. Wenn also ein Test fehlschlägt, wissen Sie, dass es ein Problem mit diesem Test und keine Interaktion mit einem anderen Test ist.

Answer 2

Normalerweise möchten Sie einen isolierten Codepfad und eine isolierte Funktion testen, und Sie möchten jedes Mal einen fairen Test durchführen. Das bedeutet, dass Sie neu starten, genau das einrichten, was Sie brauchen, und dann die Testumgebung verwerfen, wenn Sie fertig sind. Dies vermeidet das Problem verschiedener Testfälle, die Nebenwirkungen hinterlassen, die die Ergebnisse oder das Verhalten nachfolgender Läufe verändern könnten. Es bedeutet auch, dass Sie garantieren können, dass Ihre Tests unabhängig voneinander sind und dass Sie jede Teilmenge in beliebiger Reihenfolge ausführen können.

Sie werden jedoch feststellen, dass es auch ziemlich häufig vor und nach der Installation und dem Abbauen von Systemen kommt, die eine ganze Testumgebung (wie eine Datenbank oder was auch immer) als Ganzes einrichten Bündel von Unit Tests können dagegen ausgeführt werden.

Answer 3

Sie sollten wirklich versuchen, alle Mock-Objekte auf dem Stapel zu erstellen (oder Smartpointer verwenden). Auf diese Weise werden sie automatisch zerstört, wenn die Testfunktion den Bereich verlässt.

Answer 4

direkt nicht mit Tests zu tun, aber wenn Sie C++ Code, der tut Sachen wie:

MyObject *obj = CreateObject(); 

wo „obj“ kein Smart-Pointer ist oder durch eine Klasse nicht, dann haben verwaltet werden Sie Probleme. Wenn ich den Test schreiben würde, würde ich sagen:

MyObject obj; 
// tests on obj here 

Egal, was die Ergebnisse der Tests werden obj korrekt zerstört werden. Erstellen Sie ein Objekt nie dynamisch in C++, wenn Sie es möglicherweise vermeiden können.