Verborgene Testfallen in Go aufdecken: Fehlalarme vermeiden

Der Albtraum beim Testen wäre falsch positiv. „Alles vergeht! Toll!" Bis zu einem unbekannten Zeitpunkt in der Zukunft alle Minen gleichzeitig explodieren und Ihr Team in die Hölle jagen.

Es gibt viele Gründe dafür, dass Tests stillschweigend fehlschlagen können.

Heute werde ich über einen ganz grundlegenden Grund sprechen: Ich weiß nicht, was Tests sind.

Warum wissen Sie nicht, was Tests sind?

Die meisten Leute schließen sich einem Go-Projekt auf halbem Weg an. Die meisten Menschen lernen eine Sprache, indem sie sie im wirklichen Leben verwenden.

Wenn also jemand das Projekt mit einem Test-Framework wie testify eingerichtet hätte, würden Sie höchstwahrscheinlich denken, dass Methoden wie die folgenden Tests sind.

func (suite *ExampleTestSuite) TestExample() {
    suite.Equal(5, suite.VariableThatShouldStartAtFive)
}

Sie fügen dann eine weitere Methode wie TestAnotherCase hinzu und stellen fest, dass sie funktioniert. Du denkst, du weißt ganz genau, was Tests sind.

Test hat in verschiedenen Frameworks unterschiedliche Bedeutungen

Ein „Test“, von dem Sie sprechen, ist möglicherweise nicht derselbe Test, von dem ein Go-Paket spricht.

Im integrierten Testpaket ist ein Test jede Funktion der Form

func TestXxx(*testing.T)

Da das integrierte Testpaket natürlich über begrenzte Funktionen verfügt, verwenden die meisten Projekte testify/suite oder ein anderes ähnliches Drittanbieterpaket als Testframework. Was ist ein Test aus Sicht des Zeugen/der Suite?

Fügen Sie alle Methoden hinzu, die mit „Test“ beginnen, um Tests hinzuzufügen

Sehen Sie, wir haben zwei verschiedene Definitionen eines Tests.

Das Problem beginnt, wenn ein Testtool eines Drittanbieters verwendet wird

Wenn Sie einige Werkzeuge wie Spott verwenden, lesen Sie Folgendes:

Sie müssen sich keine Sorgen mehr machen, dass Sie den Aufruf der AssertExpectations-Methode vergessen … Die AssertExpectations-Methode ist für den Aufruf am Ende der Tests registriert

Großartig! „Ich muss also nur eine Simulation erstellen und das Paket benachrichtigt mich, wenn erwartete Verhaltensweisen auftreten.“

Da ist die Falle.

Wenn Spott am Ende der Tests sagt, meint das eigentlich die Definition aus Testing, nicht die Definition aus testify/suite.

Wenn Sie also den folgenden Code haben, werden Sie sehen, dass sowohl TestA als auch TestB bestanden wurden, auch wenn beide fehlschlagen sollten, da das Schein-Setup in TestA in TestB verwendet wird.

package mockandsubtest

import (
    "fmt"
    "testing"

    "github.com/stretchr/testify/suite"
)

// Prod code
type ExternalService interface {
    Work()
}

type Server struct {
    externalService ExternalService
}

func NewServer(externalService ExternalService) *Server {
    return &Server{
        externalService: externalService,
    }
}

// Test code
type ServerSuite struct {
    suite.Suite
    ExternalService *MockExternalService
    Server
}

func TestServerSuite(t *testing.T) {
    suite.Run(t, &ServerSuite{})
}

// Run before all test cases
func (s *ServerSuite) SetupSuite() {
    s.ExternalService = NewMockExternalService(s.T())
    s.Server = Server{externalService: s.ExternalService}
}

// In this test, Work is set up to be called once but not called
func (s *ServerSuite) TestA() {
    fmt.Println("TestA is running")
    s.ExternalService.EXPECT().Work().Times(1)
}

// In this test, Work is called once unexpectedly
func (s *ServerSuite) TestB() {
    fmt.Println("TestB is running")
    s.Server.externalService.Work()
}

Das Ergebnis der Ausführung des obigen Codes ist

TestA is running
TestB is running
PASS

Erläuterung

Es stellt sich heraus, dass nur TestServerSuite aus Test- und Spottsicht als Test betrachtet wird. Aus diesem Grund wird AssertExpectations am Ende von TestServerSuite aufgerufen, obwohl TestA und TestB intern von testify/suite ausgeführt werden.

Aus spöttischer Sicht wird erwartet, dass s.ExternalService einmal aufgerufen wird und tatsächlich einmal im Lebenszyklus von TestServerSuite aufgerufen wird. Die Erwartung ist also erfüllt.

Wie kann man Abhilfe schaffen?

Es gibt zwei Möglichkeiten, die Lücke zwischen Testify/Suite und Testing zu schließen.

Die erste Möglichkeit besteht darin, vor jeder Testmethode ein neues Modell wie folgt zu erstellen.

func (suite *ExampleTestSuite) TestExample() {
    suite.Equal(5, suite.VariableThatShouldStartAtFive)
}

Manchmal ist es in Ihrem Projekt aus vielen Gründen nicht praktikabel, beispielsweise weil die Einrichtung einer Serverinstanz für jeden Testfall zu teuer ist. Dann können Sie die andere Richtung ausprobieren, nämlich die manuelle Bestätigung nach jedem Test.

Die zweite Möglichkeit besteht darin, am Ende jeder Testmethode einen Aufruf von AssertExpectations hinzuzufügen. Rufen Sie beispielsweise AssertExpectations in TearDownTest auf, das nach jeder Testmethode ausgeführt wird.

func TestXxx(*testing.T)

Das obige ist der detaillierte Inhalt vonVerborgene Testfallen in Go aufdecken: Fehlalarme vermeiden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!