2017-10-13 6 views
0

J'ai trouvé le test 'go test', mais si je sous-test spécifique, il échouera, ici je donne un échantillon variable global, 'go test' passera, et 'go test -run f/sample2' échouera.Quelles sont les règles générales pour que 'go test' réussisse le '<case>' réussi comme 'go test'?

Je me demande quelles sont les règles générales que je devrais suivre pour éviter de tels problèmes?

t.go

package main 

import "fmt" 

var g string 

func f(s string) string { 
     g = g + s 
     return s + g 
} 
func main() { 
     fmt.Println(f("a")) 
} 

t_test.go

package main 

import (
     "testing" 
) 

func Test_f(t *testing.T) { 
     tests := []struct { 
       name string 
       g string 
       s string 
       r string 
     }{ 
       {"simple", "g1", "s1", "s1s1"}, 
       {"simple2", "g2", "s2", "s2s1s2"}, 
       {"simple3", "g3", "s3", "s3s1s2s3"}, 
     } 
     for _, tt := range tests { 
       t.Run(tt.name, func(t *testing.T) { 
         //g = tt.g 
         r := f(tt.s) 
         if r != tt.r { 
           t.Error("r=", r, "expect r=", tt.r) 
         } 
       }) 
     } 
} 

Si la variable globale est le problème, je vous écris souvent quelque chose comme osExit fmtPrint pour remplacer os.Exit et fmt.Print sur les tests, comment les surmonter?

Répondre

1

La façon d'éviter de tels problèmes est de ne pas avoir de tests dépendant les uns des autres. Dans votre cas, la variable globale est en effet un problème. Si vous exécutez les tests dans l'ordre, ils ont l'état global attendu. Si vous les exécutez dans le désordre, ils ne le font pas, en raison de l'interdépendance entre les tests.

La solution consiste à faire fonctionner chaque test de manière indépendante, en le faisant définir son propre état attendu. Dans ce cas, cela signifie que la variable globale g doit être définie sur la valeur attendue pour chaque test.

Une meilleure solution est de refactoriser afin de ne pas avoir de variables globales du tout.