golang-test-temp-Verzeichnis

Habe ich eine einfache Funktion, die analysiert eine config-Datei als JSON. Ich möchte einen test schreiben, die entweder verwendet einige Beispiel-statische config-Dateien und analysiert Sie, oder schafft der Proben, die während der test-und versucht zu analysieren Sie.

Es ist nicht ganz notwendig auf die Frage, aber hier ist die basic-code:

//config.go

//...(package,imports)...

//Overall settings - corresponds to main.conf
type MainSettings struct {
    //stuff
}

//Load main.conf from the specified file path
func LoadMainSettings(path string) (*MainSettings, error) {

    b, err := ioutil.ReadFile(path)
    if err != nil { return nil, err }

    r := &MainSettings{}
    err = json.Unmarshal(b, r)
    if err != nil { return nil, err }

    return r, nil

}

und der test:

//config_test.go

func TestLoadMainSettings(t *testing.T) {

    //possibly generate some example config files,
    //or use static samples packaged with the source

    s, err := LoadMainSettings("conf/main.conf") //<-- what should this path be??
    if err != nil { panic(err) }

    //more sanity checking...

}

Sagte, meine konkreten Fragen sind:

Ist es ein geeigneter Ort für statische assets (wie sample-config-Dateien), die nur für tests?
Bei der Testdurchführung gibt es eine richtige (cross-Plattform, wird aufgeräumt mit "geh'') Lage zu schreiben temporäre Dateien?

(Hinweis: ich betreibe die meisten meiner Sachen unter Linux für die Inszenierung und Produktion und Mac für lokale dev - also unter Verwendung von /tmp/als temp-dir für tests funktioniert bei mir in der Praxis. Aber eine Frage war, ob es einen besseren Weg...)

EDIT: Endete mit diesem Ansatz für den test:

f, err := ioutil.TempFile("", "testmainconf")
if err != nil { panic(err) }
defer syscall.Unlink(f.Name())
ioutil.WriteFile(f.Name(), []byte("{...sample config data...}"), 0644)

s, err := LoadMainSettings(f.Name())

Aber den anderen Vorschlag machen LoadMainSettings akzeptieren io.Reader statt einer string ist auch eine gute Idee.

Können Sie schreiben den test so verwendet er eine io.Reader direkt? Wenn dem so ist, dann wird Ihr test-case müssen nicht, hängt von der Datei-system, wie Sie Ihre tests verwenden können strings.NewReader um den entsprechenden prüfungsinhalte in der Prüfung selbst.
Hm - das ist eine interessante Idee... Etwas umständlich für den Anrufer, aber sonst, ja, das wäre in diesem Fall.
Es sollte nicht mehr umständlich für den Anrufer. Eine Datei ist eine io.Reader schon.
Stimmt - aber ein string ist nicht, aber ich bekomme Ihren Punkt. Ich Stimme zu, es ist eine gute Idee.
nur für das Protokoll, wenn Sie eine Funktion mit einem parameter path ist bequemer, man kann schreiben Sie eine öffentliche Funktion mit einem path-parameter, und rufen Sie eine private func von innen mit einem io.Reader (mit der die Datei geöffnet). Dann testen Sie nur die interne func. Das andere ist nur ein wrapper, alle es tut, ist "compiler " getestet".

InformationsquelleAutor Brad Peabody | 2013-09-29

file go testing

8

Nur zu vergleichen, gegenüber dem was Sie haben, mit ioutil.TempDir Sie hier, was die Dinge Aussehen mit io.Reader:
```
//Load main.conf from the specified file path
func LoadMainSettings(src io.Reader) (*MainSettings, error) {
    b, err := ioutil.ReadAll(src)
    if err != nil { return nil, err }

    r := &MainSettings{}
    err = json.Unmarshal(b, r)
    if err != nil { return nil, err }

    return r, nil
}
```
Speziell, wir ändern das argument von einem path string zu einem src io.Reader Instanz, und wir ersetzen die ioutil.ReadFile mit einem ioutil.ReadAll.

Den Testfall, den Sie geschrieben haben dann am Ende ein wenig kürzer, genau, da können wir verzichten Datei-Operationen:
```
s, err := LoadMainSettings(strings.NewReader("{...sample config data...}"))
```
- Recht, macht Sinn, auf das - für den test. Es bedeutet auch, dass der Anrufer in das Hauptprogramm tun würde: f, err := os.Open("conf/main.conf"); /*prüfen, ob Datei-open-Fehler*/ f aufschieben.close(); s, err := LoadMainSettings(f); Wenn die configs sind immer Lesen aus Dateien, und ich habe mehrere verschiedene Arten (LoadSomeOtherSettings(), LoadYetAnotherConfig(), etc.), Ich denke, dieser Ansatz ist vielleicht nicht der beste Weg sein. Es sei denn, ich bin fehlt etwas...
- eine andere Sache: ich denke, ich bin den Vergleich dieser meiner Erfahrung mit Java, wo Sie in der Regel haben Sie eine Ausgabe-Verzeichnis erstellt, als Teil der JUnit-test-suite-Ausführung und es enthält oft nicht nur die Ergebnisse von den tests, aber ein temp-dir, wo test Verwandte Artikel gehen kann. Und Sie wissen, dass, wenn die "sauber" ausgeführt wird, auf die es bauen, alle gehen Weg. Macht die Dinge einfach. Wurde gerade gefragt, ob es einen entsprechenden Begriff auf diese, die es in der gehen - aber wie ich sehe (und Sie zeigen sind aus) ist es wahrscheinlich besser, nur nähern sich dem problem anders.
- Yup. Temporäre Dateien sind auch in Ordnung. Sie sehen, wie Sie in der 'testdata' Unterverzeichnis packages wie golang.org/src/pkg/net/testdata. Also keine hard-und-schnell-Regel ist hier: manchmal macht es Sinn, um Ihre test-Daten in Dateien, und manchmal macht es Sinn, Sie zu integrieren in tests. Wie in Java (wo sehen Sie java.io.InputStream und java.io.Reader überall), werden Sie sehen, dass die Mehrheit der Gehen, der code arbeitet mit generischen io.Reader, also ich wollte nur sicherstellen, dass es dokumentiert wurde als Ansatz, um deine Frage irgendwo. 😛
- Amen und prost!
InformationsquelleAutor dyoo
11

Könnten Sie ioutil.TempDir oder TempFile aus dem gleichen Paket.
- Cool - ja, das ist es, was ich am Ende machen.
InformationsquelleAutor Ask Bjørn Hansen

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.