So testen Sie die Ausgabe einer Funktion (stdout / stderr) in Go-Unit-Tests

9

Ich habe eine einfache Funktion, die ich testen möchte:

%Vor%

Aber wie kann ich testen, was die Funktion tatsächlich an die Standardausgabe sendet? Test :: Output macht was ich will in Perl. Ich weiß, dass ich mein eigenes Beispiel schreiben könnte, um dasselbe in Go zu machen (wie hier hier beschrieben):

%Vor%

Aber das ist eine Menge zusätzlicher Arbeit für jeden einzelnen Test. Ich hoffe, es gibt einen Standardweg oder vielleicht eine Abstraktionsbibliothek, um damit umzugehen.

    
Flimzy 07.11.2014, 15:33
quelle

3 Antworten

16

Eine Sache, an die Sie sich auch erinnern sollten, es gibt nichts, was Sie davon abhält, Funktionen zu schreiben, um das Boilerplate zu vermeiden.

Zum Beispiel habe ich eine Kommandozeilen-App, die log verwendet, und ich schrieb diese Funktion:

%Vor%

Dann benutzte es so:

%Vor%

Verwenden Sie diese Assert-Bibliothek: Ссылка .

    
Caleb 07.11.2014, 16:50
quelle
10

Sie können eines von zwei Dingen tun. Die erste besteht darin, Beispiele zu verwenden.

  

Das Paket wird ebenfalls ausgeführt und überprüft den Beispielcode. Beispielfunktionen können einen abschließenden Zeilenkommentar enthalten, der mit "Ausgabe:" beginnt und mit der Standardausgabe der Funktion verglichen wird, wenn die Tests ausgeführt werden. (Der Vergleich ignoriert führende und nachfolgende Leerzeichen.) Dies sind Beispiele für ein Beispiel:

%Vor%

Die zweite (und geeignetere IMO) ist die Verwendung gefälschter Funktionen für Ihr IO. In Ihrem Code tun Sie:

%Vor%

Und in Ihren Tests:

%Vor%

Eine weitere Option ist die Verwendung von fmt.Fprintf mit einem io.Writer , das heißt os.Stdout im Produktionscode, aber in Tests möglicherweise auch bytes.Buffer .

    
Ainar-G 07.11.2014 15:48
quelle
1

Sie könnten in Erwägung ziehen, Ihrer Funktion eine return-Anweisung hinzuzufügen, um die tatsächlich ausgedruckte Zeichenfolge zurückzugeben.

%Vor%

Nun könnte Ihr Test einfach die zurückgegebene Zeichenfolge anhand einer erwarteten Zeichenfolge überprüfen (anstatt des Ausdrucks). Vielleicht ein bisschen mehr in Einklang mit Test Driven Development (TDD).

Und in Ihrem Produktionscode müsste sich nichts ändern, da Sie den Rückgabewert einer Funktion nicht zuweisen müssen, wenn Sie sie nicht benötigen.

    
Joe Bergevin 07.11.2014 18:13
quelle

Tags und Links