Wie os.exit Szenarien in Go

Question

Vor diesem Code

func doomed() { 
    os.Exit(1) 
} 

testen Wie richtig, dass ich testen Aufruf dieser Funktion in einem exist führt mit go test? Dies muss innerhalb einer Reihe von Tests erfolgen, mit anderen Worten, der Anruf os.Exit() kann die anderen Tests nicht beeinflussen und sollte abgefangen werden.

Answer 1

Sie können nicht, müssen Sie exec.Command verwenden und den zurückgegebenen Wert testen.

Answer 2

Ich glaube nicht, dass Sie die tatsächliche os.Exit ohne Simulation von außen (mit exec.Command) Prozess testen können.

Das heißt, könnten Sie in der Lage sein, um Ihr Ziel zu erreichen, indem eine Schnittstelle oder Funktionstyp erstellen und dann eine noop Implementierung in Ihren Tests verwenden:

Go Playground

package main 

import "os" 
import "fmt" 

type exiter func (code int) 

func main() { 
    doExit(func(code int){}) 
    fmt.Println("got here") 
    doExit(func(code int){ os.Exit(code)}) 
} 

func doExit(exit exiter) { 
    exit(1) 
} 

Answer 3

-Code für die Prüfung:

package main 
import "os" 

var my_private_exit_function func(code int) = os.Exit 

func main() { 
    MyAbstractFunctionAndExit(1) 
} 

func MyAbstractFunctionAndExit(exit int) { 
    my_private_exit_function(exit) 
} 

Testing Code:

package main 

import (
    "os" 
    "testing" 
) 

func TestMyAbstractFunctionAndExit(t *testing.T) { 
    var ok bool = false // The default value can be omitted :) 

    // Prepare testing 
    my_private_exit_function = func(c int) { 
     ok = true 
    } 
    // Run function 
    MyAbstractFunctionAndExit(1) 
    // Check 
    if ok == false { 
     t.Errorf("Error in AbstractFunction()") 
    } 
    // Restore if need 
    my_private_exit_function = os.Exit 
} 

Answer 4

Es gibt eine presentation von Andrew Gerrand (eines der Kernmitglieder des Go-Teams), wo er zeigt, wie es geht.

eine Funktion (in main.go)

package main 

import (
    "fmt" 
    "os" 
) 

func Crasher() { 
    fmt.Println("Going down in flames!") 
    os.Exit(1) 
} 

hier Bedenkt man, wie man es (durch main_test.go) prüfen würde:

package main 

import (
    "os" 
    "os/exec" 
    "testing" 
) 

func TestCrasher(t *testing.T) { 
    if os.Getenv("BE_CRASHER") == "1" { 
     Crasher() 
     return 
    } 
    cmd := exec.Command(os.Args[0], "-test.run=TestCrasher") 
    cmd.Env = append(os.Environ(), "BE_CRASHER=1") 
    err := cmd.Run() 
    if e, ok := err.(*exec.ExitError); ok && !e.Success() { 
     return 
    } 
    t.Fatalf("process ran with err %v, want exit status 1", err) 
} 

der Code Was tut, ist go test wieder in einem separaten Prozess aufrufen durch exec.Command , Begrenzung der Ausführung auf den TestCrasher Test (über den -test.run=TestCrasher Schalter). Es gibt auch ein Flag über eine Umgebungsvariable (BE_CRASHER=1) weiter, die der zweite Aufruf überprüft und, falls gesetzt, das zu testende System aufruft, um unmittelbar danach zurückzukehren, um zu verhindern, dass es in eine Endlosschleife läuft. Daher werden wir in unsere ursprüngliche Call-Site zurückversetzt und können nun den tatsächlichen Exit-Code validieren.

Quelle: Slide 23 der Präsentation von Andrew. Die zweite Folie enthält auch einen Link zu der presentation's video. Er spricht über subprocess Tests bei 47:09

Answer 5

ich tun dies, indem bouk/monkey mit:

func TestDoomed(t *testing.T) { 
    fakeExit := func(int) { 
    panic("os.Exit called")  
    } 
    patch := monkey.Patch(os.Exit, fakeExit) 
    defer patch.Unpatch() 
    assert.PanicsWithValue(t, "os.Exit called", doomed, "os.Exit was not called") 
} 

Affe ist super-leistungsfähige, wenn es um diese Art von Arbeit kommt, und zur Fehlerinjektion und andere schwierige Aufgaben. Es kommt with some caveats.